1.프로토콜 2.TCP 3.UDP 4.FTP 5.HTTP 6.출처

1. HTTP 프로토콜 개요
-TCP, UDP, FTP, HTTP
2014. 09. 30
Version : 1.0.0
This material is proprietary to DGMIT. It contains trade secrets and confidential information which is solely the property of DGMIT.
This material is solely for the Client’s internal use. This material shall not be used, reproduced, copied, disclosed, transmitted,
in whole or in part, without the express consent of DGMIT © All rights reserved.
made by 이슬기
R&D1 팀

2. 2
CONTENTS.
1. 프로토콜 ………………… 3
2. TCP ……………………… 4
3. UDP ……………………… 5
4. FTP ……………………… 6
5. HTTP ……………………… 7
6. 출처 ……………………… 16

3. 3
1. 프콜토콜
통신프로토콜이란 ?
- 통신을 원하는 객체 사이에서
무엇을 ,
통신할 것인지를 서로 약속한 규정입니다 .
어떻게 ,
언제

4. 4
2. TCP
TCP( 연결형 프로토콜 )
- 연결 설정 후 데이터 교환

5. 5
3. UDP
UDP( 비연결형프로토콜 )
- 연결설정하지 않고 데이터 교환

6. 6
4. FTP
FTP(TCP 사용 )
- 파일을 효율적으로 주고 받을 수 있는 파일 전송 프로토콜
- 연결 2 개 중 하나는 파일 전송용 , 다른 하나는 제어용
- 파일 전송용은 파일을 전송할 때마다 생성
- 제어용은 클라이언트쪽에서 서버쪽으로 명령을 내리고 서버에 응답을 하려고 할 때 사용
- 서버는 FTP 의 포트 21 로 수동적 개방 , 클라이언트의 접속을 대기
- 클라이언트는 제어를 연결하려고 TCP 포트 21 을 능동적으로 개방
- 클라이언트는 연결된 제어를 통해 파일전송 요청
- 서버는 FTP 의 임시 포트로 클라이언트와 연결 설정기
- 서버는 연결을 이용해 클라이언트에 파일을 전송
- 파일을 전송 후 서버는 연결을 해제
- 클라이언트는 원하는 파일을 전부 수신하였으면 연결을 해제
- 서버는 클라이언트의 접속을 대

7. 7
5. HTTP
HTTP 에 대하여
- HTTP(Hypertext Transfer Protocol) 은 인터넷상에서 데이터를 주고 받기 위한 서버 / 클라이언트 모델을 따르는 프로토콜
- 애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동
- HTTP 는 어떤 종류의 데이터든지 전송할 수 있도록 설계
(HTML 로 작성된 문서 , 이미지 , 동영상 , 오디오 , 텍스트 문서 , …)
- 하이퍼텍스트 기반으로 데이터를 전송 ( 링크기반으로 데이터에 접속 )

8. 8
5. HTTP
작동방식
- HTTP 는 서버 / 클라이언트 모델
클라이언트에서 요청을 보내면 (Request)
서버는 요청을 처리해서 응답 (Response).
* 클라이언트 : 서버에 요청하는 클라이언트 소프트웨어가 설치된 컴퓨터 .
Chrome, firefox, ie 등의 클라이언트 소프트웨어를 이용 .
클라이언트는 URI를 이용해서 서버에 접속 및 데이터를 요청 가능 .
* 서버 : 클라이언트의 요청을 받아서 , 요청을 해석하고 응답을 하는 소프트웨어가 설치된 컴퓨터 .
Apache, nginx, IIS, lighttpd 등이 서버 소프트웨어 .

9. 9
5. HTTP
Connectless & stateless
- HTTP 는 Connectless 방식으로 작동 . 서버에 연결하고 , 요청해서 응답을 받으면 연결을 끊음 .
- 장점 : 불특정 다수를 대상으로 하는 서비스에 적합한 방식 .
수십만명이 웹 서비스를 사용하더라도 접속 유지는 최소 .
더 많은 유저의 요청을 처리 가능 .
- 단점 : 연결을 끊어버리기 때문에 , 클라이언트의 이전 상태를 알 수 없음 .
Stateless - Connectless 로부터 파생되는 특징 .
예) 클라이언트가 과거에 로그인을 성공하더라도 , 로그 정보를 유지불가 .
HTTP 는 cookie 를 이용 .
*cookie 는 클라이언트와 서버의 상태 정보를 담고 있는 정보 조각 .
예 ) 클라이언트가 로그인에 성공
→ 서버는 로그인 정보를 자신의 데이터베이스에 저장하고 동일한 값을 cookie 형태로 클라이언트에 보냄
→ 클라이언트는 다음 번 요청때 cookie 를 서버에 보냄
→ 서버는 cookie 값으로 자신의 데이터 베이스를 조회하여 로그인 여부 확인 가능

10. 10
5. HTTP
URI(Uniform Resource Identifiers)
- 클라이언트 프로그램 ( 이하 웹 브라우저 ) 은 URI로 자원 위치를 검색
- HTTP 는 전송 프로토콜 , URI 는 자원의 위치를 알려주기 위한 프로토콜 .
* World Wide Web 상에서 접근하고자 하는 자원의 위치를 나타내기 위해서 사용 .
* 자원은 " 문서 ", " 이미지 ", " 동영상 ", " 프로그램 ", " 이메일 " 등 가능 .
예)
email:sklee@dgmit.com ( 메일 받을 상대방 위치 )
http://www.dgmit.com/01_main/01_main.html ( 웹페이지의 위치 )
- http: 자원에 접근하기 위해 http 프로토콜 사용 .
- www.dgmit.com/01_main/ : 자원의 인터넷 상에서의 위치 .
- 도메인은 ip 주소로 변환되므로, ip 주소로 서버의 위치 접근 가능 .
- 01_main.html : 요청할 자원의 이름 .
“ 프로토콜” , “ 위치” , “자원명”으로 ( 인터넷 상에서 ) 어디에 있던 지 자원에 접근 가능 .

11. 11
5. HTTP
Method(메서드)
- 메서드는 요청의 종류를 서버에게 알려주기 위하여 사용 .
GET 정보를 요청하기 위해서 사용한다 . (SELECT)
POST 정보를 밀어넣기 위해서 사용한다 . (INSERT)
PUT 정보를 업데이트하기 위해서 사용한다. (UPDATE)
DELETE 정보를 삭제하기 위해서 사용한다 . (DELETE)
HEAD (HTTP)헤더 정보만 요청한다. 해당 자원이 존재하는지 혹은 서버에 문제가 없는지를 확인하기 위해서 사용한다
.
OPTIONS 웹서버가 지원하는 메서드의 종류를 요청한다.
TRACE 클라이언트의 요청을 그대로 반환한다 . 예) echo 서비스로 서버 상태를 확인하기 위한 목적으로 주로 사용한다
.
- 보통 웹 서비스들은 GET 과 POST 만을 이용해서 개발
(1) GET 과 POST 만으로도 모든 종류의 요청을 표현 가능
http://www..sample.com/bbs?id=1234&action=delete
(2) 편하게 개발
(3) 웹 브라우저로 DELETE, HEAD 등을 보내는 form 이 없음
- 명시적으로 메서드를 사용하지 않아도 웹 서비스 개발에 큰 문제는 없지만 , 가능하면 CRUD 를 명시 .

12. 12
5. HTTP
요청 데이터 포멧
- 웹 브라우저는 웹 서버에 데이터를 “요청”하는 “클라이언트 프로그램”
- 요청은 서버가 인식할 수 있는 약속된 형식 (HTTP) 으로 .
- 요청 데이터는 “ HEADER”와 “ BODY” 로 구성 .
HEADER
BODY
- 헤더에는 요청과 요청데이터에 대한 메타정보들이 들어있습니다 .
1 GET /cgi-bin/http_trace.pl HTTP/1.1rn
2 ACCEPT_ENCODING: gzip,deflate,sdchrn
3 CONNECTION: keep-alivern
4 ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8rn
5 ACCEPT_CHARSET: windows-949,utf-8;q=0.7,*;q=0.3rn
6 USER_AGENT: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.24rn
7 ACCEPT_LANGUAGE: ko-KR,ko;q=0.8,en-US;q=0.6,en;q=0.4rn
8 HOST: www.joinc.co.krrn
9 rn
1 필수 요소 ( 요청 메서드 , 요청 URI, HTTP 프로토콜 버전 )
2 지원 인코딩 : HTTP 1.1 부터 웹 서버는 네트워크 대역폭을 아끼기 위해서 데이터 압축 기능을 제공한다 .
웹 브라우저가 지원하는 인코딩을 적어보내면 , 웹 서버는 이 중 지정된 방식으로 데이터를 인코딩한다 .
3 연결 방식 : HTTP 1.1은 연결유지 (persistent connection) 기능을 지원한다 .
기본적으로 HTTP 는 하나의 요청당 하나의 연결을 맺는 방식이다 .
하나의 웹 페이지에 이미지를 포함해서 10 여개의 객체가 있다면 10번 연결을 맺었다 끊어야 한다 .
소켓 통신에서 연결은 매우 비용이 많이 들어가는 연산으로 비효율적인 방식이다 .
keep-alive 를 사용하면 하나의 연결에 여러 요청을 보낼 수 있다 .
4 ACCEPT : 클라이언트가 지원하는 미디어 타입
5 ACCEPT_CHARSET : 클라이언트가 지원하는 문자 셋
6 USER_AGENT : 클라이언트의 버전 , 운영체제 등을 명시한다 .
예 ) 모바일기기로 접근할 경우 , 서버는 이 정보를 읽어서 모바일 환경에 맞게 데이터를 조정해서 보낼 수 있다 .
7 ACCEPT_LANGUAGE
8 HOST : 정보를 요청하는 서버의 주소 .
헤더 종료 : 줄 처음에 rn을 명시해서 , 헤더가 끝났다는 것을 서버에게 알려준다 .

13. 13
5. HTTP
응답 헤더 포멧
- wget 을 이용하면 헤더 정보를 가져올 수 있음 .
# wget -S http://www.test.co.kr wget 으로 헤더 정보를 출력했다 .
HTTP/1.1 200 OKrn 응답프로토콜 , 응답코드 , 응답메시지
...
서버는 응답코드로 서버의 상태를 알려줌 .
3 자리의 숫자로 구성됨 .
예 )
HTTP/1.1 200 OKrn
HTTP/1.1 404 Not Foundrn
HTTP/1.1 500 Internal errorrn
2xx 성공
서버가 요청을 성공적으로 처리했음을 의미한다 .
200 성공 서버가 요청을 제대로 처리함
201 생성됨 요청이 성공했으며 새로운 리소스 생성
202 허용됨 요청을 받았으나 , 아직 처리하지 못함
204 컨텐츠 없음 요청을 처리했지만 , 컨텐츠를 제공하지 않음
205 컨텐츠 재 설정 요청을 처리했지만 , 컨텐츠를 표시하지 않음 , 그리고 문서를 재설정할 것을 요구
206 일부 성공 요청의 일부만 성공적으로 처리
207 다중상태
4xx 요청 오류
클라이언트 요청에 오류가 있음을 의미한다 .
400 잘못된 요청 주로 헤더 포멧이 HTTP 규약에 맞지 않을 경우
401 권한 없음 인증을 필요로 하는 요청이다 .
403 금지 서버가 요청을 거부하고 있다 .
404 찾을 수 없음 요청한 자원이 서버에 존재하지 않는다 .
405 허용하지 않는 방법 요청에 지정한 방법을 사용할 수 없다 .
406 허용되지 않음 요청한 페이지를 콘텐츠 특성 때문에 응답할 수 없다 .
408 요청시간 초과 서버의 요청대기가 시간을 초과
410 사라짐 요청한 자원이 삭제되었음 . 404와 비슷하지만 , 410 은 과거에 있었으나 지금 없는 자원이다 . 예 ) 게시판에서 삭제한 포스트에 접근하는 경우
411 길이필요 유효한 컨텐츠 길이를 명시해야 한다 .

14. 5. HTTP
셰션관리
- HTTP 를 기반으로 하는 웹 서비스는 connectless 방식으로 이전의 상태정보 유지불가 .
- 클라이언트의 상태 정보를 정보 조각 형태로 서버와 클라이언트 ( 웹 브라우저 )에 남기는 방식 .
- 이 정보조각을 cookie( 이하 쿠키 ) 라고 함 .
- 서버는 cookie 를 이용해서 세션정보를 관리 .
- 세션과 cookie 관계를 정리하자면
서버는 클라이언트와 cookie 를 주고 받는 것으로 상태를 확인할 수 있다 .
ex) 클라이언트가 로그인을 한 상태인지
서버는 cookie 를 키로하는 값을 데이터베이스에 저장하는 방식으로 " 세션 " 을 유지한다 .
ex) 로그인한 클라이언트가 " 물건 - A" 를 구매했다면 , 클라이언트의 cookie id 를 key 로 데이터베이스에 구매정보를 update.
14

15. 5. HTTP
HTTP 응용 : REST
- HTTP 가 CRUD 요소를 모두 가지고 있다는 것에 착안하여 , 웹 상에서 데이터를 처리하기 위한 아키텍처를 제안한 것 .
- 장점 : 추가적인 레이어나 세션 관리등을 추가하지 않고도 HTTP 프로토콜만을 이용해서 데이터를 전송 가능 .
HTTP 기반의 소프트웨어 인프라를 그대로 활용가능
- RESTful 서비스 : REST 아키텍처를 개발하는 서비스
- 특징 (HTTP 기반이므로 HTTP 의 특징과 장점을 그대로 가짐 .)
: HTTP 만으로 데이터를 전송하고 처리할 수 있다 .
: Stateless
: ROA( 리소스 기반 아키텍처 ) - URI 를 이용해서 자원에 접근 .
: 단순하며 사용하기 쉽다 .
- REST 의 이런 단순 명로함 때문에 구글 , 트위터 , 야후등이 자신들의 서비스를 REST 방식으로 제공하고 있다 .
- 개발자를 끌어들이기 위한 OpenAPI 역시 REST 을 기반으로 하면서 , REST 의 사용을 활성화 시켰다 .
- RESTFul API (REST 기반의 API)
GET api.joinc.co.kr/user/list 유저 목록을 가져온다.
POST api.joinc.co.kr/user/create 유저를 생성.
생성에 필요한 유저 정보는 POST 데이터 형식으로 전달가능.
PUT Api.joinc.co.kr/usr/123 유저 ID 가 123 인 유저의 정보를 업데이트 .
DELETE Api.joinc.co.kr/user/123 유저 ID 가 123 인 유저를 삭제.
15

16. 16
6.
출처
참고서적 , URI
- TCP 연결 설정 이미지 http://luciferd.tistory.com/entry/Network-09-2603-Chapter3
- TCP 연결 해제 이미지 http://wearehacker.com/network/60234
- UDP TCP 이미지 http://z0mbi2.tistory.com/62
- FTP 동작 원리 이미지 http://skbstory.tistory.com/590
- < 최신 정보통신 개론 -유비쿼터스 컴퓨텅개념까지( 개정판)> 한빛미디어
- http://www.joinc.co.kr/modules/moniwiki/wiki.php/Site/Network_Programing/AdvancedComm/HTTP#s-1

17. 17 본사/ 기업부설연구소 : 135-874 서울특별시 삼성동 봉은사로 424 TROA 빌딩 5 층
Tel. 070-8680-1770 Fax. 02-2179-9114 http://www.dgmit.com