HTTP : 웹의 기초
-
웹 콘텐츠의 원천
-
어떤 종류의 콘텐츠 소스도 리소스가 될 수 있다
- HTTP에서 데이터 타입을 구분하기 위해 사용
- MIME 타입을 사용한다 (ex : text/html, image/jpeg ..)
- Uniform Resource Identifier
- 정보 리소스를 고유하게 식별하고 위치를 지정
- URL
- Uniform Resource Locator
- 특정 서버의 한 리소스에 대한 구체적인 위치를 서술
- URN
- 콘텐츠를 이루는 한 리소스에 대해 그 리소스의 위치에 영향 받지 않는 유일무이한 이름
-
요청 명령과 응답 결과로 구성
- 서버에게 어떤 동작이 취해져야 하는지 알려주는 것
- 클라이언트에게 응답 결과를 알려주는 세자리 숫자
-
시작줄, 헤더, 본문으로 구성
- HTTP가 사용하는 전송 계층 프로토콜
- 오류 없는 데이터 전송, 순서에 맞는 전달, 조각나지 않는 데이터 스트림을 보장
- 프록시 : 클라이언트와 서버 사이에 위치한 HTTP 중개자
- 캐시 : 많이 찾는 웹페이지를 클라이언트 가까이에 보관하는 HTTP 창고
- 게이트웨이 : 다른 애플리케이션과 연결된 특별한 웹 서버
- 터널 : 단순히 HTTP 통신을 전달하기만 하는 특별한 프록시
- 스킴 : 리소스를 가져오기 위한 프로토콜
- 호스트 : 접근 하려는 리소스를 가지고 있는 인터넷상의 호스트 장비
- 포트 : 서버가 열어 놓은 네트워크 포트 (HTTP 기본 : 80)
- 사용자 이름 & 비밀번호 : 일부 프로토콜에서 필요한 정보
- 경로 : 리소스가 서버의 어디에 있는지 알려주는 정보
- 파라미터 : 프로토콜의 파라미터(?)(생소해서 추가 정보가 필요합니다...)
- 질의 : 요청 받을 리소스 형식의 범위를 좁히기 위해 사용하는 정보
- 프래그먼트 : 리소스의 특정 부분을 가리키기 위한 정보(서버에 전송되지 않고 클라이언트에서만 사용)
- URL은 기본적으로 US-ASCII 의 7비트로 나타낼 수 있는 문자만 사용해야함
- US-ASCII로 나타낼 수 없는 문자를 URL에 사용하기 위한 방법
- %문자로 시작해 나타냄
- 인바운드 : client to server
- 아웃바운드 : server to client
- 업스트림 : 메시지의 송신자
- 다운스트림 : 메시지의 수신자
- 모든 메시지는 다운스트림 방향으로 흐른다
- 요청 메시지
<메서드><요청URL><버전>
<헤더>
<엔터티 본문>
- 응답 메시지
<버전><상태 코드><사유 구절>
<헤더>
<엔터티 본문>
- 메서드 : 클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작
- 요청 URL : 요청 대상이 되는 리소스를 지칭하는 완전한 URL 혹은 URL의 경로 구성요소
- 버전 : 이 메시지에서 사용중인 HTTP의 버전
- HTTP/<메이저>.<마이너> ex) HTTP/1.1
- 상태 코드 : 요청 중에 무엇이 일어났는지 설명하는 세 자리의 숫자
- 사유 구절 : 상태코드를 설명해주는 문구로 실제 동작과는 무관
- 헤더 : 요청과 응답 메시지의 추가 정보
- 엔터티 본문 : 임의의 데이터 블록으로 있을수도 없을수도 있음
- 일반 헤더 : 요청과 응답 양쪽에 나타날 수 있음, 메시지에 대한 아주 기본적인 정보를 제공
- 요청 헤더 : 요청에 대한 부가 정보를 제공 ex) referer, cookie
- 응답 헤더 : 응답에 대한 부가 정보를 제공 ex) set-cookie
- Entity 헤더 : 본문 크기와 콘텐츠 혹은 리소스 그 자체를 서술 ex) Allow, Content-Length
- 확장 헤더 : 명세에 정의되지 않은 새로운 헤더
- URL에서 호스트명을 추출
- 호스트명에 대한 IP 주소를 검색
- 포트번호를 추출
- IP 주소와 포트 번호를 이용해서 TCP 커넥션을 생성
- HTTP 요청을 보냄
- HTTP 응답을 받음
- 커넥션 종료
- IP 패킷이라 불리는 작은 조각을 이용해 데이터를 전송
- IP 패킷 내부에는 잘개 쪼개진 데이터 스트림인 세그먼트가 들어있음
- <발신지 IP 주소, 발신지 포트, 수신지 IP 주소, 수신지 포트> 네가지 값으로 커넥션을 구분하고 생성
- 연결이 완료되면 연결이 제대로 되었는지 확인하는 패킷을 서버에서 보내고 클라이언트에서 응답함
- 간단한 TCP 요청이라면 이 과정 자체가 오버헤드
- TCP는 세그먼트를 받으면 확인 응답 패킷을 송신자에게 전송
- 이 확인 응답에 대한 응답을 받지 못하면 해당 세그먼트를 수신자는 폐기
- 송신자는 보낸 세그먼트에 대한 확인 응답 패킷을 받지 못하면 해당 세그먼트를 재전송
- 응답 패킷이 작으므로, 다른 패킷에 묶어서 전송해서 네트워크를 효율적으로 이용하는 것이 편승
- 편승할 응답패킷을 기다리다가 존재 하지 않으면 별도 응답 패킷을 전송
- 이 응답패킷을 기다리는 시간이 지연 요소
- HTTP는 편승이 일어날 확률이 적음
- TCP 커넥션이 막 만들어졌을때는 속도 제한을 걸고, 시간이 지날수록 차차 제한을 해제함
- 네트워크 대역폭을 초과해서 전송함으로써 데이터 유실이 생기는것을 방지하기 위한 혼잡제어 알고리즘 중 하나
- TCP 세그먼트는 플래그와 헤더를 기본적으로 포함해야 하므로 여러 작은 TCP 데이터를 하나로 합쳐서 전송하는 알고리즘
- 확인 응답 지연과 합쳐지면 더더욱 성능을 낮추는 원인
- Connection 헤더에 들어 있는 헤더 필드명은 수신자가 응답을 보낼 때 포함되어서는 안됨(hob-by-hob)
- http/1.0에서 지속 커넥션을 사용하기 위해 보내야 하는 헤더
- http/1.1에서는 지속 커넥션이 기본값이므로 필요한 헤더가 아니지만, Http/1.0으로 통신하는 상황에 대비해 대부분의 브라우저에서 이 헤더를 보낸다
- http/1.1에서 커넥션이 종료되었음을 명시적으로 알려주는 헤더
- http/1.1의 기본 커넥션은 지속 커넥션이므로, 연결이 종료되었다면 반드시 보내야 하며 존재하지 않을 경우 커넥션이 살아있다고 간주한다.
- http/1.0에서는 기본 커넥션이 1회성이므로 별도로 존재하지 않는다.
- keep-alive 헤더는 지속 커넥션의 정보를 알려주는 값으로 timeout, max 두 파라미터로 정보를 전달한다
- Connection : keep-alive 헤더와 반드시 같이 존재해야하며, hop-by-hop 헤더이다.
- timeout은 지속 커넥션이 얼마나 오래 유지될지, max는 몇개의 트랜잭션까지 이 커넥션으로 처리할지를 나타내며 하나의 커넥션으로 트랜잭션을 수행할 때 마다 max 값이 줄어드는것을 확인할 수 있다.
- 동시에 커넥션 여러개를 이용해 병렬로 내려받음
- 반드시 항상 더 빠르지는 않음(대역폭 이슈, 성능 이슈)
- 사용자에게 더 빠르게 느껴질 수 있음
- 처리가 완료되어도 커넥션을 유지하는 방법
- HTTP/1.1 에서는 기본적으로 활성화 되어있고 연결을 끊기 위해서는 Connection:close 헤더를 포함해서 전송
- 요청을 파이프라이닝해서 전송
- POST 요청과 같은 비멱등(nonidempotent) 요청을 이 커넥션을 이용해서 보내면 안됨
- 커넥션의 입출력을 모두 끊는 방법과 한 방향만 끊는 절반 끊기 방법이 있음
- 우아하게(?) 커넥션을 끊으려면 보통 출력 커넥션을 끊고 입력 커넥션을 주기적으로 검사하면서 끊는 방법을 사용
책 이외의 추가 정보 출처
https://developer.mozilla.org/ko/docs/Web/HTTP/Headers
https://tools.ietf.org/html/rfc7230#section-appendix-A.1.2
https://tools.ietf.org/id/draft-thomson-hybi-http-timeout-01.html#rfc.section.2
http://ktword.co.kr/word/abbr_view.php?m_temp1=3391
https://developer.mozilla.org/ko/docs/Web/HTTP/Connection_management_in_http_1.x