HTTP 1.1
- 인터넷 연결을 위한 TCP application protocol
- request-response 모델 : 하나의 request이 발생하면 response가 나가고 연결이 끝남
- Text 기반 Protocol : 어떤 프로토콜은 바이너리 형식으로 묶여 있어 내용을 이해하기 어려운 경우도 있지만 HTTP는 텍스트 형식으로 주어져 읽기 편하다.
- Chunk 단위의 Encoding
- Compression(압축) 지원
- 인증 쪽에서는 Cookie, Session 지원
- Virtual Host 지원
Status Line
- 요청
- {METHOD} {TARGET} {HTTP/VERSION}
- ex. POST / HTTP/1.1
- 응답
- {HTTP/VERSION} {STATUS_CODE} {REASON}
- ex. HTTP/1.1 403 Forbidden
HTTP STATUS CODE
- 200대 : 정상적으로 성공했을 때
- 300대 : 리다이렉션이 필요할 때(다른 데에 자료가 있을 때)
- 400대 : request의 정보가 오류가 있을 때, request를 잘못 보냈을 때
- 500대 : 서버가 죽었을 때
HTTP Method
- GET : 리소스 조회
- POST : 리소스 추가
- PUT : 리소스 교체
- DELETE : 리소스 삭제
- PATCH : 리소스 변경
- OPTIONS : 메소드 조회, 해당 타겟에 어떤 메소드들이 가능한지 조회
- HEAD : GET 상태 조회, BODY는 관심 없고 HEAD만 가져오겠다 할 때(서비스가 정상적으로 살아있는지만 가져오기 위해)
- HTTP Method는 CRUD에 대응 가능하다
- Create = POST
- Read = GET
- Update = PUT
- Delete = DELETE
- PUT vs POST
- 원칙 : 멱등성(Idempotent)
- POST는 idempotent 하지 않다.
- PUT은 idepotent 하다.
- 사례 : 주민등록 시스템에 출생신고 하기
- 공무원이 김민수라는 사람에 대해 출생신고 버튼을 연속 3번 눌렀을 경우
- POST : 김민수라는 동명이인이 3명 등록됨
- PUT : 두번째, 세번째 요청은 주민등록번호가 같기 때문에 버려짐
표준 헤더
User Agent
- 서버나 네트워크가 어플리케이션이나 운영체제 장비나 버전을 감지하기 위한 문자열
- 운영체제, 브라우저 프로그램, 디바이스 등 분리 가능
- User-Agent : /
- User Agent 읽는 법
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)
- Mozilla = Application Name
- /4.0 = Application Version
- compatible = Compatiblity Flag
- MSIE 7.0 = Version Token
- Windows NT 6.0 = Platform Token
- 최근 User Agent의 중요성이나 가치가 크게 떨어진 이유는?
- 웹 개발자
- 과거에 User-Agent를 체크해서 개발을 했다.
- 브라우저마다 동작이 조금씩 상이하니 User Agent 기반으로 페이지를 개발(User Agent가 모질라면 이렇게 만들고, 익스플로러면 이렇게 만들고...)
- 브라우저 개발자
- 우리는 모질라 것도 잘나오고, 익스플로러 것도 잘 나와. 모질라도 넣고 인터넷 익스플로러도 넣자.
- 역으로 User Agent를 꼬아서 호환성을 만드려 함
Accept
- 응답이 어떻게 넘어와야 하는지 설명해주는 헤더
- Aceept : 컨텐츠 타입이 무엇인지 (이미지, 텍스트, 오디오...)
- Accept: text/html, application/xhtml+xml, application/xml;q=0.9, /;q=0.8
- text/html은 가중치가 1, application/xhtml+xml도 가중치가 1, application/xml은 0.9, /(전체)은 가중치가 0.8
- 서버가 가중치 순서대로 보낼 수도 있고, 이미지만 받는 장치라면 가중치가 0.1인 이미지를 보낼 수 도음
- Accept-Encoding: 인코딩이 무엇인지 (gzip 압축인지, 풀어서 오는지…)
- Accept-Encoding: deflate, gzip;q=1.0, *;q=0.5
- Accept-Language: 이해할 수 있는 언어가 무엇인지
- Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5
Content
- 서버가 응답한 컨텐츠를 설명해주는 헤더
- Content-Type: 컨텐츠가 이미지인지, 텍스트인지 등
- Content-Type: text/html; charset=utf-8
- Content-Length: 컨텐츠의 크기를 반환
- Content-Encoding: 컨텐츠의 인코딩 형식을 설명함
- Content-Encoding: deflate, gzip
Access-Control-Allow-Origin
Access-Control-Request-Headers
Access-Control-Request-Method
Access-Control-Max-Age
Authorization
비표준 헤더(X-API)
- 헤더의 키 값은 콜론으로 구분되기 때문에 개발자가 임의로 만든 키에 임의의 밸류를 넣을 수 있음
- X-API의 경우 키가 'x-'로 시작하는 비표준 헤더
HTTP over TCP
- Keep-Alive 옵션
-
HTTP Request 이후에 TCP Connection이 닫히지 않게 해준다.
-
TCP Connection 맺는데 비용이 발생
-
HTTP는 보통 여러개 요청 보내기 마련, 커넥션을 살려두면 재활용이 가능하다. = Persistant HTTP
- Pipelining
- Chunked Encoding
- Range 요청
- 비디오 스트리밍을 요청하기 위해서 잘린 구간을 요청할 수 있다.
HTTP 2.0 (SPDY)
- 구글이 2009년에 제안한 SPDY 프로토콜
- 웹 표준 WG에서 SPDY를 기반으로 한 2.0을 정의함
- 특징
- Binary Protocol
- 96만 5432라는 숫자를 만약에 우리가 데이터를 보낸다고 가정. 문자열로 보내려면 9 6 5 4 3 2 여섯 글자니까 6바이트로 데이터를 보내야 된다. 근데 만약에 숫자로 보낸다고 하면, 대충 4바이트 인트 변수 하나에 그냥 날릴 수 있다.
- HTTP 프로토콜을 처음 만들 때에는 1kb, 2kb, 이런 내용만 주고받을 줄 알아서 설계했었던 프로토콜이었는데. 여기에 사람들이 이미지도 보내고 음악도 보내고 하다못해 이제 동영상까지 보내기 시작하니까 텍스트로 보내는 게 너무 비효율적이 돼서 이 바이너리로 바꾸는 프로토콜을 제안.
- Header Compression
- 이전에는 바디 쪽은 gzip 압축을 했지만, 헤더 부분은 압축에 대한 스펙 정의하지 않았었다.
- Multiplexing
- 데이터 여러 개 보내면 계층을 나눠 한 번에 데이터를 많이 보낼 수 있게 멀티플렉싱도 하겠다.
- Server Push
- 클라이언트가 서버한테 데이터를 무조건 보내야만 HTTP 프로토콜이 시작이 됐었는데, 서버에서 먼저 데이터를 보내주는 것도 하나의 프로토콜로 정의를 하겠다.
HTTP 3.0 (QUIC)
CDN
- 개별 서버 장소에 인터넷 사용자가 많은 서비스에 대응하기 위해 복수의 서버를 네트워크로 연결하여 구성
- 접속 경로 최적화 효과
- 지리 데이터 정보에서 사용자 PC까지의 경로 탐색하여 가장 빠른 경로로 연결
- Cache 기능
- CDN으로 작동하는 서버는 요청을 받아 요청하는 웹 페이지에 데이터를 조립
- 서비스: AWS CloudFront