Http 완벽 가이드 -정리-

HTTP: 웹의 기초

어떤 종류의 콘텐츠 소스도 리소스이다.

인터넷은 수천가지의 데이터 포멧을 다루기 때문에 HTTP는 식별을 위해 MIME 타입이라는 데이터 포맷 라벨을 붙인다.

웹 서버는 모든 HTTP 객체 데이터에 MIME 타입을 붙인다.

웹 브라우저는 응답 받은 MIME 타입 포맷에 따라 데이터를 디코딩한다

 

MIME 타입

주 타입(파일의 종류)/부 타입(파일의 형식) 으로 이루어진 문자열 라벨

MIME type

• text : 텍스트 정보
• multipart : 다른 MIME 타입들을 가진 합성된 문서
• audio : 오디오 파일
• video : 비디오 파일
• application : 모든 이진 데이터 전송

* MIME 형식에는 공백, 대/소문자를 구분하지 않으며 대부분 소문자로 쓰입니다.

 

URI : 정보 리소스를 고유하게 식별할 수 있게 하는 것

URL : 정보 식별을 구체적인 위치를 통해 식별한다

URN : 정보 식별을 고유한 이름으로 식별한다.

* URN 장점 - 프로토콜이나 리소스의 위치에 영향을 받지 않는다, 단점 - 구현 어렵다(인프라 자원 필요)

 

URL 구조 

• 스킴 : 프로토콜 명시, 기본값 : 없음
• 사용자 이름 : 특정 프로토콜 리소스에 접근하기 위해 필요, 기본값 : anonymous
• 비밀번호 : 사용자의 비밀 번호, 사용자 이름에 콜론(:)으로 이어서 기술, 기본값 <이메일 주소>
• 호스트 : 리소스를 호스팅하는 서버의 호스트 명이나 ip 주소
• 포트 : 호스팅하는 서버가 열어 놓은 포트 번호(기본 http 80), 기본값 : 스킴에 따라 다름
• 경로 : 서버내 리소스가 어디에 위치하는 지를 가르킨다
• 파라미터 : 특정 스킴에서 입력 파라미터를 기술하는 용도 
• 질의 : 스킴에서 애플리케이션에 파리미터를 전달하는 데 사용, url 끝에 ?로 구분
• 프래그먼트 : 리소스의 조각이나 일부분을 가르키는 이름 (일반적으로 http는 일부가 아닌 전부를 다루기 때문에 브라우저가 프래그먼트를 사용하여 보고자 하는 리소스를 보여준다) 

URL은 상대 URL과 절대 URL로 나뉜다

절대 URL은 모든 정보를 가지고 있음, 상대 URL은 모든 정보를 가지고 있지 않음, 필요한 모든 정보를 얻기 위해 base url(기저 url)을 사용해야 한다

 

상대 참조 해석 알고리즘

 

url은 이스케이프 기능을 통해 안전하지 않은 문자(아스키 코드에 없는 문자)를 인코딩한다. 인코딩에서 문자는 % 기호로 시작하는 문자로 바뀐다.

url에서 선점되어 있는 문자는 그전에 인코딩 해야 한다

• 선점 문자 : %  /  .  ..  # ? ; : $ + @ & = {} | \ ~ [] <> " 0x00-0x1F >0x7F 등
• 어떤 문자를 인코딩해야 하는 지는 최초 URL 입력받은 어플리케이션에서 담당
• URL 처리하기 전에 디코딩하여 유효성 검사해야 한다

 

트랜잭션

HTTP 트랜잭션은 요청명령과 응답결과로 구성되어 있음

 

메서드

HTTP 요청 메시지는 한 개의 메서드를 갖는다

ex) GET, PUT, DELETE, POST, HEAD 등

 

상태 코드

HTTP 응답 메시지는 상태 코드와 반환, 상태 코드는 세가지 숫자이다

ex) 2xx : 정상, 3xx: 리다이렉션 , 4xx: 클라이언트 오류 , 5xx: 서버 오류

 

애플리케이션은 하나의 작업을 수행하기 위해 여러 HTTP 트랜잭션을 수행한다

 

프로토콜 버전

• HTTP/0.9 : GET 메서드만 지원
• HTTP/1.0 : 처음으로 널리 쓰이기 시작한 HTTP 버전
• HTTP./1.0+ : keep-alive 커넥션 등 기능 추가, HTTP 확장 버전
• HTTP/1.1 : 현재 HTTP버전, 성능 최적화 및 잘못된 기능 제거 버전
• HTTP/2.0 : HTTP/1.1 성능 개선(HOL BLOCKING 등을 해결 하기 위해 만들어짐, 응답 순서와 상관없이 주고 받음)

웹 구성요소 : 프록시, 캐시, 게이트 웨이, 터널, 에이전트

* 프록시와 게이트 웨이는 서버끼리 통신의 중개자 역할을 한다. 차이점은 게이트웨이는 주로 HTTP 프로토콜을 다른 프로토콜로 변환하기 위해 사용된다

* 터널 : 두 커넥션 사이에서 RAW 데이터를 열어보지 않고 그대로 전달해주는 역할

HTTP 메시지

HTTP 메시지는 HTTP 애플리케이션 간에 주고 받는 데이터의 블록

메시지는 시작줄, 헤더 블록, 본문으로 구성

시작줄과 헤더는 줄 단위로 분리된 아스키 문자열, 각 줄은 줄바꿈 문자열로 끝난다

본문은 선택적인 데이터 덩어리, 본문이 텍스트 일수도 이진 데이터 일수도 비어 있을 수 도 있다

 

HTTP 메시지 방향 용어

• 인바운드 : 메시지가 원 서버로 향하는 것(서버 방향)
• 아웃바운드 : 처리후 메시지가 사용자 에이전트로 돌아오는 것(사용자 방향)
• HTTP 메시지는 강물 처럼 흐름, 모든 메시지는 다운스트림으로 흐른다
  • ex) 클라이언트 -> 서버, 클라이어트는 서버의 업스트림, 서버는 클라이언트의 다운스트림

모든 HTTP 메시지는 요청 메시지나 응답 메시지로 분류

요청 메시지 : 웹 서버에 어떤 동작을 요구, 응답 메시지 : 요청의 결과를 반환

 

요청 메시지 형식

  <메서드> <요청url> <버전>
  <헤더>
  
  <엔터티 본문>

* 메서드 : 서버가 리소스에 대해 수행해주길 바라는 동작(GET, POST, PUT, DELETE 등)

* 버전 : 사용중인 HTTP 버전 (HTTP/<메이저>.<마이너>)

 

응답 메시지 형식

  <버전> <상태 코드> <사유 구절>
  <헤더>
  
  <엔터티 본문>

* 버전 : 사용중인 HTTP 버전 (HTTP/<메이저>.<마이너>)

* 상태코드 : 요청 중에 무엇이 일어났는지 설명하는 세자리 숫자

* 사유 구절 : 사람에게 읽히기 위한 목적, 메시지 영향을 주지 않음

헤더 분류 

• 일반 헤더 : 요청과 응답 양쪽 모드 나타날 수 있음
• 요청 헤더 : 요청에 대한 부가 정보 제공
• 응답 헤더 : 응답에 대한 부가 정보 제공
• Entity 헤더 : 본문 크기와 콘텐츠, 혹은 리소스 그 자체를 서술
• 확장 헤더 : 명세에 정의되지 않은 헤더

HTTP 메서드 

• GET : 서버에게 리소스를 달라고 요청
• HEAD : GET 처럼 행동하지만, 바디가 없음 HEAD만 돌려준다
• PUT : 서버에 문서를 쓴다. 요청 URL의 이름대로 새 문서를 만들거나 요청 본문으로 교체한다
• POST: 서버에 입력 데이터를 전송하는 목적, HTML 폼에 흔히 사용
• TRACE : 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이는지 알려준다, 진단을 위해 사용
• OPTIONS : 웹 서버에게 여러 가지 종류의 지원 범위에 대해 물어본다 ex) 지원 메서드 
• DELETE : 서버에게 요청 URL로 지정한 리소스 삭제를 요청한다

상태 코드 

* 100 : 클라이언트가 나머지를 계속 보내야함. 서버는 반드시 요청을 받아 응답해야한다

• 클라이언트 : 큰 엔티티를 쪼개기 위해 사용, 100-continue로 하는 Expect 요청 헤더를 보낸다
• 서버 : 100-continue 값이 담긴 Expcet 헤더 요청을 받는다면 100 Continue응답 또는 에러 코드로 답해야한다
• 프록시 : 서버와 클라이언트의 버전에 맞추어 작동, 하위 버전일 경우 100-continue응답 전달 x or 417 에러 응답

http1.0에서 302는 post -> get으로 리다렉트 한다. http1.1 에서는 prg 패턴을 303으로 사용한다. http1.1에서 method를 유지하는(post->post) 307을 만들었고 302는 http1.0을 위해 남겨 두었다. 

 

커넥션 관리

HTTP가 메시지를 전송하고자 할 경우,현재 연결되어 있는 TCP 커넥션을 통해서 메시지 데이터의 내용을 순서대로 보낸다

클라이언트 -> 서버 과정

• 호스트 명을 추출하고 호스트명에 대한 IP 주소 찾는다
• 브라우저가 포트 번호 80을 얻는다 80포트로 <host ip,host 포트, server ip, server 포트> TCP 커넥션을 생성한다
• 브라우저가 서버로 HTTP 요청을 보내고 응답 받는다
• 브라우저가 커넥션을 끊는다

TCP 커넥션은 <host ip,host 포트, server ip, server 포트> 값으로 식별한다

Transport 계층 - 세그먼트, Network 계층 - 패킷

IP 패킷 헤더(20 Byte) + TCP 세그먼트 헤더(20 Byte) + TCP 데이터 조각

 

대부분의 HTTP 지연은 TCP 네트워크 지원 때문에 발생한다

HTTP 트랜잭션 지연시키는 원인

• 클라이언트 URL에서 웹 서버의 IP주소와 포트 번호를 알아야 한다
• 클라이언트는 TCP 커넥션 요청을 서버에게 보내서 서버가 커넥션 허가 응답을 회신하기를 기다린다
• 새로 생성된 TCP 파이프를 통해 요청이 전달되며 응답시 까지 시간이 소요된다

TCP 지연

• 핸드세이크 지연 : 각 트랜잭션이 마다 새로운 커넥션이 이루어지기 때문에 발생. 크기가 작은 트랜잭션은 50%이상의 시간을 TCP 구성하는데 사용된다
• 확인 응답 지연 : 패킷 전송을 보장하기 위해 각 TCP 세그먼트는 순번과 체크섬을 가진다. 보통 확인 응답은 같은 방향으로 가는 데이터 패킷에 편승하여 보낸다. 확인 응답을 위한 버퍼를 두고 편승할 패킷을 찾으며, 찾지 못하면 별도의 패킷을 만들어 보낸다(확인 응답 지연 알고리즘). HTTP 특성상 해당 편승할 기회가 많지 않기 때문에 확인 응답 지연시키는 알고리즘으로 인한 지연이 발생한다
• 느린 시작 지연 : 인터넷의 갑작스러운 부하를 막기 위해 처음 보내는 패킷의 수를 제한한다. 이후 패킷수를 점차 늘려가며 네트워크 상태에 따라 패킷 수를 조절한다(혼잡제어).
• 네이글 알고리즘 : 네트워크의 효율을 위해 한번에 많은 양의 TCP 데이터를 보내는 기법. 확인 응답이 도착하기 전까지 패킷을 쌓다가, 확인 응답을 기다리는 패킷이 확인 응답을 받거나 버퍼에 충분한 패킷이 쌓였을 때 데이터가 전송된다. 확인 응답 지연과 같이 함께 쓰일 경우 지연이 더 발생할 수 있음(확인 응답을 받기 전까지 기다림 + 편승하기 위해 확인 응답 지연)
• TIME_WAIT의 누적과 포트 고갈 : TCP 커넥션을 끊을시 이전 커넥션의 패킷이 새로운 커넥션에 간섭하지 못하게 보통 세그먼트의 최대 생명주기의 두 배(보통 2분) 정도 동안 해당 커넥션을 재생성 불가하게 한다.  

커넥션

Connection 헤더는 hop by hop 이다. 커넥션 토큰이 HTTP 헤더 명을 가지고 있으면, 해당 필드들은 현재 커넥션만을 위한 정보이다. 

• 순차적인 커넥션 : 트랜잭션 마다 커넥션을 만든다. 순차적으로 이루어진다
• 병렬 커넥션 : 여러 개의 TCP 커넥션을 통해 동시 HTTP 요청
• 지속 커넥션 : 커넥션을 맺고 끊는 데서 발생하는 지연을 제거하기 위해 재사용 한다. 
• 파이프라인 커넥션 : 지속 커넥션을 경우 일때만 사용 가능하다. 

 

 

 

참고자료 :

HTTP (https://www.popit.kr/%EB%82%98%EB%A7%8C-%EB%AA%A8%EB%A5%B4%EA%B3%A0-%EC%9E%88%EB%8D%98-http2/)

HTTP METHOD (https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/307)