HTTP Header 구조

HTML 파일 안에 text, image 파일이 있을때 request header

GET /NewFile.html HTTP/1.1
Host: localhost:9090
Connection: keep-alive
Cache-Control: max-age=0
sec-ch-ua: "Chromium";v="86", "\"Not\\A;Brand";v="99", "Google Chrome";v="86"
sec-ch-ua-mobile: ?0
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Sec-Fetch-Site: none
Sec-Fetch-Mode: navigate
Sec-Fetch-User: ?1
Sec-Fetch-Dest: document
Accept-Encoding: gzip, deflate, br
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7



GET /Users/jaeho/image-analysis.png HTTP/1.1
Host: localhost:9090
Connection: keep-alive
sec-ch-ua: "Chromium";v="86", "\"Not\\A;Brand";v="99", "Google Chrome";v="86"
sec-ch-ua-mobile: ?0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36
Accept: image/avif,image/webp,image/apng,image/*,*/*;q=0.8
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: no-cors
Sec-Fetch-Dest: image
Referer: http://localhost:9090/NewFile.html
Accept-Encoding: gzip, deflate, br
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7




GET /favicon.ico HTTP/1.1
Host: localhost:9090
Connection: keep-alive
sec-ch-ua: "Chromium";v="86", "\"Not\\A;Brand";v="99", "Google Chrome";v="86"
sec-ch-ua-mobile: ?0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36
Accept: image/avif,image/webp,image/apng,image/*,*/*;q=0.8
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: no-cors
Sec-Fetch-Dest: image
Referer: http://localhost:9090/NewFile.html
Accept-Encoding: gzip, deflate, br
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7

 

이게 처음 요청한 문서안에 다른 파일들이 있으면 그 파일에 대한 요청이 다시 또 들어온다~

 

http header의 종료를 알리는건

 

newline이다~

 

 

1. Get

 

GET  /NewFile.html  HTTP/1.1

 

브라우저에 localhost:9090/NewFile.html이라고 입력하면 request Header에 저렇게 출력됨

 

GET: 지정된 리소스(URI)를 요청

 

POST: 서버가 클라이언트의 폼 입력 필드 데이터의 수락을 요청. 클라이언트는 서버로 HTTP Body에 Data를 전송

 

HEAD: 문서의 헤더 정보만 요청하며, 응답데이터(body)를 받지 않는다.

 

PUT: 클라이언트가 전송한 데이터를 지정한 uri로 대체한다. ftp의 PUT과 동일하며, 클라이언트는 서버로 HTTP Body에 Data를 전송한다.

 

DELETE: 클라이언트가 지정한 URI를 서버에서 삭제한다.

 

TRACE: 클라이언트가 요청한 자원에 도달하기 까지의 경로를 기록하는 루프백(loop back) 검사용. 클라이언트가 요청 자원에 도달하기

              까지 거쳐가는 프록시나 게이트웨이의 중간 경로부터 최종 수진 서버까지의 경로를 알아낼때 사용.

---

(2) host

 

서버의 ip : 포트번호

 

---

(3) Connection 

 

Keep-alive

 

HTTP는 아시다 시피 connection less 방식으로 연결을 매번 끊고 새로 생성하는 구조입니다. 이는 network 비용측면에서 많은 비용을 소비하는 구조입니다.( 최초 연결하기 위한 준비과정을 의미함 ) 그래서 HTTP 1.1부터는 Keep-Alive라는 기능을 지원합니다.

Keep Alive란?
Keep Alive란 연결된 socket에 IN/OUT의 access가 마지막으로 종료된 시점부터 정의된 시간까지 access가 없더라도 대기하는 구조입니다. 즉 정의된 시간내에 access가 이루어진다면 계속 연결된 상태를 유지할 수 있다는 것 이죠.

 

HTTP 下에서 Keep Alive란?
HTTP는 앞서 설명드린 것과 같이 connection less방식이라 매번 socket(port)를 열어야 하고 이는 비용적인 측면에서 비효율적인 구조입니다. 해서 keep Alive time out내에 client에서 request를 재 요청하면 socket(port)를 새로 여는 것이 아니라 이미 열려 있는 socket(port)에 전송하는 구조가 됩니다.

예를 들면 image를 4개를 보여주는 구조에서 client는 동시에 2개의 image만 얻어 올수 있고 1개의 image는 얻는데 2초 걸리고 port를 여는데 1초가 걸린다고 가정.

keep alive : false 처음 server에 2개의 port를 열고 image를 얻고 client socket의 닫고 ( 3초 ) 다시 server에 2개의 port를 열고 image를 얻고 client socket을 닫음 ( 3초 ) 총 6초가 걸림. keep alive : true 처음 server에 2개의 port를 열고 image를 얻고 ( 3초 ) 다시 첫번째 요청에서 열어 둔 2개의 port에 2개의 image를 얻음 ( 2초 ) keep alive time out이 되었을 때 client의 socet이 닫히거나 browser가 더 이상 얻어 올 것이 없으면 자동으로 닫어 버림. 총 5초가 걸림.

 

---

(4) cache-Control

 

max-age=0 vs no-cache vs no-store

• max-age = n: 초 단위로 캐시 신선도를 설정한다. 예를 들어 60 * 60 = 3600을 입력하면 한 시간, 3600 * 24 = 86400을 입력하면 하루동안 캐시가 유지된다. 그 이후엔 서버에 요청한 뒤 304 응답을 받을 때에만 캐시를 이용한다.
• no-cache: 캐시가 유효한지 확인하기 위해 매번 서버에 요청한다.
• no-store: 어떤 요청도 캐시로 저장하지 않는다.

max-age는 캐시의 수명을 결정하는 정책이며, no-cache와 no-store는 캐시의 행동 방식을 결정하는 정책이다. 캐시를 항상 무효화하기

 

위해 max-age=0를 설정하는 곳도 있는데, 사실 no-cache를 이용하면 더 깔끔하게 해결할 수 있다.

 

다만 no-cache와 no-store는 방식이 서로 다르다. no-cache는 캐시를 저장하되 캐시가 유효한지 매번 서버에 질의하는 것이고, 

 

no-store는 아예 캐시를 저장하지 않는 것이다.

 

완벽한 캐싱 방지를 위해서는 헤더 설정을 이렇게 할 수 있다.

 

Cache-Control : no-cache, no-store, must-revalidate

 

(5) Accept

 

클라이언트가 허용할 수 있는 파일 형식(MIME TYPE)으로 */*은 특정 유형이 아닌 모든 파일형식을 지원한다는 의미가 됩니다.

(6) User-Agent

클라이언트 소프트웨어(브라우저, os 등)의 이름과 버전 등. 위의 정보에서는 MS IE 6.0, 윈도우 XP, .NET Framework 1.1 버전이 클라이언트에 설치되어 있음을 나타냅니다.

(7) 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는 요청의 부하를 줄이고 있습니다.

(7) Refer

특정 페이지에서 링크를 클릭하여 요청을 하였을 경우에 나타나는 필드로써 링크를 제공한 페이지를 나타냅니다.

 

(8) Cookie

위의 요청에는 없지만 자주 등장하는 필드입니다. 웹서버가 클라이언트에 쿠키를 저장해 놓았다면 해당 쿠키의 정보를 이름-값 쌍으로 웹서버에 전송합니다.

(9) Accept-Language

클라이언트가 인식할 수 있는 언어로 우선 순위 지정이 가능합니다.

 

(10) Accept-Encoding

클라이언트가 인식할 수 있는 인코딩(압축_방법으로 위의 내용에서는 서버에서 gzip, deflate로 압축한 리소스를 클라이언트가 해석할 수 있다는 말이 됩니다. 만일 서버에서 압축을 했다면 응답헤더에 Content-Encoding 헤더에 해당 압축 방법이 명시됩니다.