- 프로토콜
통신 프로토콜 또는 통신 규약은 컴퓨터나 원거리 통신 장비 사이에서 메시지를 주고 받는 양식과 규칙의 체계이다.
통신 프로토콜은 신호 체계, 인증, 그리고 오류 감지 및 수정 기능을 포함할 수 있다.
- http (요청하고 응답받고 끊어진다.)
HTTP(HyperText Transfer Protocol, 하이퍼본문전송규약)는 web 상에서 정보를 주고받을 수 있는 프로토콜이다. 주로 HTML 문서를 주고받는 데에 쓰인다. TCP와 UDP를 사용하며, 80번 포트를 사용한다.
HTTP는 클라이언트와 서버 사이에 이루어지는 요청/응답(request/response) 프로토콜이다. 예를 들면, 클라이언트인 웹 브라우저가 HTTP를 통하여 서버로부터 웹페이지나 그림 정보를 요청하면, 서버는 이 요청에 응답하여 필요한 정보를 해당 사용자에게 전달하게 된다.
메세지 포맷은 요청 라인 또는 응답 라인, 헤더, 바디로 구성되어 있다.
응답을 한 이후에는 연결이 끊어지기 때문에 비상태 프로토콜이라고 하는데, HTTP 1.1버전부터 일정한 시간(초단위)동안 같은 클라이언트를 대상으로 연결을 유지시켜주는 Kepp-alive가 가능합니다. 이는 현재의 css, js, 이미지 등이 많이 포함된 홈페이지를 요청하고 응답할때 유리하다
- 특징
- HTTP 메시지는 HTTP 서버와 HTTP 클라이언트에 의해서 해석이 된다.
- TCP/IP를 이용하는 응용 프로토콜(application protocol)입니다.
- TCP는 데이터의 송수신을 위해 IP를 사용하는 프로토콜이며, TCP는 UDP의 비해서 복잡하지만 신뢰성이 높기 때문에 대부분 이 프로토콜을 사용한다, 순서를 부여하여 패킷이 섞이지않게 한다.
- HTTP는 연결 상태를 유지하지 않는 비연결성 프로토콜입니다. (이러한 단점을 해결하기 위해 Cookie와 Seesion 등장)
- 또 KeepAlive를 사용, 초단위로 연결상태를 살려두어 대용량등을 주고받을때 사용한다.
- HTTP는 연결을 유지하지 않는 프로토콜이기 떄문에 요청/응답(request/response) 방식으로 동작합니다.
- https
HTTPS는 소켓 통신에서 일반 텍스트를 이용하는 대신에, SSL이나 TLS 프로토콜을 통해 세션 데이터를 암호화한다.
HTTPS의 기본 TCP/IP 포트는 443이다.
- http 헤더의 구성
Get /test/test.htm HTTP/1.1
Accept: */*
Accept-Language: ko
Accept-Encoding: gzip, deflate
If-Modified-Since: Fri, 21 Jul 2006 05:31:13 GMT
If-None-Match: "734237e186acc61:a1b"
User-Agent: Mozilla/4.0(compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1)
Host: localhost
Connection: Keep-Alive
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
X-Powered-By: ASP.NET
Date: Fri, 21 Jul 2006 05:32:01 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Fri, 21 Jul 2006 05:31:52 GMT
ETag: "689cb7f885acc61:a1b"
Content-Length: 101
요청 헤더
(1) GET /test/test.htm HTTP/1.1
요청 method와 요청 파일정보, http 버전
HTTP 프로토콜은 클라이언트가 서버에게 요청하는 방식에 대한 몇가지 동작을 정의하고 있습니다.
즉, 요청 method란 클라이언트가 서버로의 요청하는 방법을 명시합니다.
GET: 지정된 리소스(URI)를 요청
POST: 서버가 클라이언트의 폼 입력 필드 데이터의 수락을 요청. 클라이언트는 서버로 HTTP Body에 Data를 전송
HEAD: 문서의 헤더 정보만 요청하며, 응답데이터(body)를 받지 않는다.
PUT: 클라이언트가 전송한 데이터를 지정한 uri로 대체한다. ftp의 PUT과 동일하며, 클라이언트는 서버로 HTTP Body에 Data를 전송한다.
DELETE: 클라이언트가 지정한 URI를 서버에서 삭제한다.
TRACE: 클라이언트가 요청한 자원에 도달하기 까지의 경로를 기록하는 루프백(loop back) 검사용. 클라이언트가 요청 자원에 도달하기 까지 거쳐가는 프록시나 게이트웨이의 중간 경로부터 최종 수진 서버까지의 경로를 알아낼때 사용.
(2) Accept
클라이언트가 허용할 수 있는 파일 형식(MIME TYPE)으로 /은 특정 유형이 아닌 모든 파일형식을 지원한다는 의미가 됩니다.
(3) User-Agent
클라이언트 소프트웨어(브라우저, os 등)의 이름과 버전 등. 위의 정보에서는 MS IE 6.0, 윈도우 XP, .NET Framework 1.1 버전이 클라이언트에 설치되어 있음을 나타낸다. mozila 3.0~ 이런식으로 브라우저라는 걸 알려주는 것이다.
(4) Host
요청을 한 서버의 Host입니다.
(5) If-Modified-Since
페이지가 수정되었으면 최신 버전 페이지 요청을 위한 필드, 만일 요청한 파일이 이 필드에 지정된 시간 이후로 변경되지 않았다면, 서버로부터 데이터를 전송받지 않습니다. 이 경우 서버로부터 notmodified(304) 상태코드를 전송받게 됩니다.
HTTP/1.1 304 Not Modified
Server: Microsoft-IIS/5.1
Date: Fri, 21 Jul 2006 06:23:04 GMT
X-Powered-By: ASP.NET
ETag: "689cb7f886acc61:a1b"
Content-Length: 0
위의 헤더 정보는 동일한 파일을 재 요청했을때의 응답헤더입니다. 파일 변경사항이 없으므로 304(수정되지 않음)과 Content-Length: 0(데이터 받지 않음) 응답을 받았습니다. 이렇게 함으로써 http는 요청의 부하를 줄이고 있습니다.
(6) Refer
위의 요청 헤더에는 나와 있지 않지만 이 정보도 헤더에 자주 등장하는 필드입니다. 특정 페이지에서 링크를 클릭하여 요청을 하였을 경우에 나타나는 필드로써 링크를 제공한 페이지를 나타냅니다.
(7) Cookie
역시 위의 요청에는 없지만 자주 등장하는 필드입니다. 웹서버가 클라이언트에 쿠키를 저장해 놓았다면 해당 쿠키의 정보를 이름-값 쌍으로 웹서버에 전송합니다.
(8) Accept-Language
클라이언트가 인식할 수 있는 언어로 우선 순위 지정이 가능합니다.
(9) Accept-Encoding
클라이언트가 인식할 수 있는 인코딩(압축_방법으로 위의 내용에서는 서버에서 gzip, deflate로 압축한 리소스를 클라이언트가 해석할 수 있다는 말이 됩니다. 만일 서버에서 압축을 했다면 응답헤더에 Content-Encoding 헤더에 해당 압축 방법이 명시됩니다.
응답 헤더
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
X-Powered-By: ASP.NET
Date: Fri, 21 Jul 2006 05:32:01 GMT
Content-Type: text/html
Accept-Ranges: bytes
Last-Modified: Fri, 21 Jul 2006 05:31:52 GMT
ETag: "689cb7f886acc61:a1b"
Content-Length: 101
(1) HTTP/1.1 200 OK
HTTP 버전과 응답 코드(200 성공)
(2) Server
웹서버 정보를 나타냅니다. 위의 정보에서는 MicrosoftIIS 5.1 입니다.
(3) Date
현재 날짜
(4) Content-Type
요청한 파일의 MIME 타입을 나타냅니다. Text/html은 Text 중 html 파일임을 나타냅니다.
(5) Last-Modified
요청한 파일의 최종 수정일을 나타냅니다.
(6) Content-Length
헤더 이후 이어지는 데이터의 길이입니다(바이트 단위)
이어지는 데이터란 요청한 파일의 데이터라 보시면 됩니다.
(7) ETag
캐쉬 업데이트 정보를 위한 임의의 식별 숫자
- 쿠키
- 모든 도메인은 끝에 .이 생력되어있다. 최소 갯수는 2개가 있어야 쿠키가 전송된다
- naver.com. 처럼 되어있는데 naver.com에 해당할 때 쿠키가 전송되는 것이다.
- path별로 // 쿠키 전송
- 모든 도메인은 끝에 .이 생력되어있다. 최소 갯수는 2개가 있어야 쿠키가 전송된다
- 쿠키를 사용하는 이유
사용하는 방식은 다양하며, 단순히 접속에 대한 정보나 ID 만을 저장하는 데 그치지 않고, 세션 혹은 접속 시간 등 다양한 정보를 기록하기도 한다.
쿠키는 도메인별로 브라우저가 Storage 에 관리하는 형태의 정보로, 브라우저가 쿠키의 보안을 관리한다.
클라이언트가 서버에게 쿠키를 보낸다는 점이 중요한데, 대부분의 경우 특별한 제약 등을 정의하지 않으면 Cookie 는 서버로 향하는 모든 요청과 함께 전송된다.
주로 쿠키를 사용하는 목적은 다음과 같다.
- Authentication : 세션 관리.
- User Tracking : 유저 방문 추적
- Personalization : 테마, 언어 등 커스텀화된 설정에 대한 목적
