2.2 웹과 HTTP(2)

2.2.3 HTTP 메시지 포맷

HTTP 요청 메시지

ex)

1
2
3
4
5
GET /somedir/page.html HTTP1.1
Host: www.abc.com
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr

• 메시지가 일반 아스키 텍스트로 쓰여있어 우리가 읽을 수 있다.
• 메시지는 5줄로 되어있고 각 줄은 CR(carriage return, \r)과 LF(line feed, \n)로 구별된다.
  • CR : \r, 맨 앞으로 이동하라는 뜻
  • LF: \n, 새로운 라인
• 첫 줄을 요청 라인(request line)이라고 부른다.
  • 3개의 필드로 구성 : method(GET), URL(/somedir/page.html), HTTP 버전(HTTP1.1)
• 이후의 줄들은 헤더 라인(header line)이라고 부른다.
  • 요청하는 객체가 존재하는 호스트(Host) 명시
    • TCP 연결에서 이미 알게 되었지만, 웹 프록시 캐시에서 필요함
  • 비지속 연결 명시(Connection)
  • 요청을 보내는 브라우저 타입(User-agent)
  • 객체의 언어 버전(Accept-language) : 서버에 있다면 프랑스어로 보낼 것
• 헤더라인 이후에 개체 몸체(entity body)가 있음.
  • POST 방식에서만 존재하는, 클라이언트가 채워 넣는 곳
  • GET요청에서는 body 대신 URL 끝에 parameter로 추가됨(https://url.com?…)
• HEAD 방식
  • HTTP 메시지로 응답하고, 요청 객체를 보내지 않음
  • 개발자의 디버깅에 많이 사용
• PUT, DELETE, …

HTTP 응답 메시지

ex)

1
2
3
4
5
6
7
HTTP/1.1 200 OK
Connection: close
Date: Tue, 18 Aug 2015 15:44:04 GMT
Server: Apache/2.2.3 (CentOS)
Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html

• 3개의 섹션으로 구성 : 상태 라인(status line), 6개의 헤더 라인(header line), 개체 몸체(entity body)
• 상태 라인(status line)
  • 3개의 필드로 구성
    • 프로토콜 버전(HTTP/1.1)
    • 상태 코드(200)
    • 해당 상태 메시지(OK)
• 헤더 라인(header line)
  • Connection : 클라이언트에게 메시지를 보낸 후 TCP 연결을 닫음(비지속 연결)
  • Date : 서버가 응답을 생성하고 보낸 날짜와 시간
  • Server : 메시지가 아파치 웹 서버에 의해 만들어짐(요청의 User-agent와 비슷한 역할)
  • Last-Modified: 객체가 생성되거나 마지막으로 수정된 시간과 날짜. 로컬 클라이언트와 네트워크 캐시 서버(프록시 서버) 캐싱에 중요한 정보.
  • Content-Length: 송신되는 객체의 바이트 수
  • Content-Type: 개체 몸체(entitiy body)의 내부의 객체가 HTML 텍스트임을 표시. 객체 타입은 파일확장자가 아닌 Content-Type으로 표시함.
• 상태코드와 메시지
  • 200 OK : 요청이 성공했고, 정보가 응답으로 보내짐
  • 301 Moved Permanently : 요청 객체가 영구적으로 이동됨. 새로운 URL은 응답의 헤더 Location에서 찾을 수 있음.
  • 400 Bad Request : 서버가 요청을 이해할 수 없다는 일반 오류 코드
  • 404 Not Found : 요청 객체가 서버에 존재하지 않음
  • 505 HTTP Version Not Supported : 요청 HTTP 프로토콜 버전을 서버가 지원하지 않음

2.2.4 사용자와 서버 간의 상호작용: 쿠키

• HTTP 서버는 상태를 유지하지 않기 때문에 서버 설계를 간편하게 하고 동시에 수 많은 TCP 연결을 다룰 수 있다.
• 서버가 사용자 접속을 제한하거나 사용자에 따라 콘텐츠를 제공하려면 웹사이트가 사용자를 확인해야 한다.
• 쿠키는 사이트가 사용자를 추적하게 해준다.
• 쿠키 기술의 4가지 요소
  1. HTTP 응답 메시지 쿠키 헤더 라인
  2. HTTP 요청 메시지 쿠키 헤더 라인
  3. 사용자의 브라우저에 사용자 종단 시스템과 관리를 지속시키는 쿠키 파일
  4. 웹사이트의 백엔드 데이터베이스 **
• 클라이언트가 처음 서버에 접속하면, 서버는 유일한 식별번호를 만들고 이것으로 인덱싱되는 엔트리를 백엔드 DB안에 만든다.
• 서버의 응답 헤더에 Set-cookie: 를 포함하고 이 식별변호를 담아 보낸다.
• 클라이언트는 받은 응답의 Set-cookie를 브라우저가 관리하는 특정한 쿠키 파일에 덧붙인다.
• 여기엔 서버의 호스트 이름과 Set-cookie: 헤더와 식별번호가 포함된다.
• 브라우저가 관리하는 쿠키 파일에는 다른 사이트에 대한 쿠키들도 포함되어있다.
• 앞으로 클라이언트가 서버에 보내는 요청의 헤더에 Cookie : 헤더를 포함하여 보낸다.
• 서버는 이 쿠키를 통해, 어떤 사용자가 어떤 행동들을 했는지 알 수 있다.
• 최근 웹사이트에 접속했을 때 쿠키 사용 요청에 대한 동의를 구하는데 이 쿠키다.

2.2.5 웹 캐싱

• 웹 캐시(Web cache) 는 프록시 서버(proxy server)라고도 한다.
• 기점 웹 서버(origin Web server)를 대신하여 HTTP 요구를 충족시키는 네트워크 개체다.
• 웹 캐시는 자체의 저장 디스크를 갖고 있어 최근 호출된 객체의 사본을 저장한다.
• 웹 캐시는 서버이면서 클라이언트다.
• 클라이언트가 웹 캐시에게 요청을 보낸다.
  • 만약 웹 캐시가 요청에 맞는 객체를 갖고 있다면 클라이언트에게 응답으로 객체를 보낸다.
  • 만약 갖고 있지 않다면 웹 캐시가 서버에게 TCP 연결을 설정하여 객체를 받아 저장한다.
  • 그리고 클라이언트에게 저장한 객체의 사본을 보내준다.
• 클라이언트의 입장에선 웹 캐시는 서버이고, 서버의 입장에선 웹 캐시는 클라이언트가 된다.
• 웹 캐시를 사용하는 이유
  1. 클라이언트의 요구에 대한 응답시간 감소
     1. 특히 서버보다 웹 캐시와 연결 속도가 높다면 더욱 효과적
  2. 한 기관에서 인터넷으로의 접속하는 링크상의 웹 트래픽을 줄일 수 있다.
     1. 예를 들어, 수 십대의 클라이언트와 기점 서버들이 있다고 가정하자.
     2. 기관 네트워크에 있는 수 십대의 클라이언트는 하나의 기관 라우터로 모인다.
     3. 공중 인터넷에 있는 기점 서버들도 마찬가지로 하나의 인터넷 라우터로 모인다.
     4. 기관 네트워크와 기관 라우터, 기점 서버들과 인터넷 라우터들 간의 속도가 아무리 빨라도, 두 라우터 사이의 속도가 느리다면 응답시간은 몹시 느려진다.
     5. 두 라우터 사이의 회선을 개선하는 것은 물리적, 비용적으로 부담이 크다.
     6. 따라서 클라이언트들 처럼, 기관 라우터와 연결뒌 웹 캐시를 만든다.
     7. 필요한 객체가 웹 캐시에 있다면 인터넷의 라우터로 갈 필요 없이 빠른 속도로 웹 캐시가 요청을 처리할 수 있다.
     8. 서버 입장에선, 웹 캐시와 기관 라우터사이의 속도만 신경쓰면 된다.
• CDN(Content Distribution Network, 컨텐츠 전송 네트워크)가 웹 캐시를 활용한 것.

조건부 GET

• 웹 캐싱에서 생각해볼 문제는, 복사되어 저장된 객체가 과연 최신버전인지 여부이다.
• 조건부 GET(conditional GET) : **HTTP는 클라이언트가 브라우저로 전달되는 모든 객체가 최신의 것임을 확인하면서 캐싱을 하게 해준다.
• HTTP 요청 메시지가
  1. GET 방식을 사용
  2. If-Modified-Since: 헤더를 가지고 있다면

  조건부 GET이다.

• If-Modified-Since 에 입력된 날짜 이후의 수정된 경우에만 응답에 객체를 담아 보낸다.
• 날짜 이후로 수정된 것이 없다면 빈 개체 몸체를 보내고 응답 메시지는 304 Not Modified 를 나타낸다.
• 수정되지 않았으니 복사된 것을 사용하라는 의미이다.

2.2.6 HTTP/2

• 1997년 표준화된 HTTP/1.1 이 후 새로운 표준(2015년)
• 1.1은 지속 연결(TCP)로 웹 페이지 당 하나의 TCP 연결을 가지도록 할 수 있었다.
• 이는 HOL(Head of Line) 블로킹 문제를 야기했다.
• 예를 들어, 대용량의 비디오 객체와 작은 참조 객체들이 존재한다고 가정하자.
  • 하나의 TCP 연결을 통해 비디오 객체와 참조 객체들이 전송된다.
  • 중간에 낮은 속도의 병목구간이 있다면 비디오 객체가 전송될 때까지 용량이 작은 참조 객체들은 기다려야 한다.
• 이 문제를 해결하기 위해, 1.1은 여러 개의 병렬 TCP 연결을 사용하여 해결하는 방식을 취한다.

HTTP/2 프레이밍

• 앞서 말한 비디오 객체를 1000개의 프레임으로 나눈다.
• 참조 객체들은 각각 2개의 프레임으로 구성된다.
• 기존 HOL 상황이면, 비디오의 프레임 1000개가 전송된 이후 참조 객체들의 프레임이 전송된다.
• HTTP/2 에선 비디오 프레임 1개를 보낼 떄마다 참조 객체 프레임도 1개 보낸다.
• 비디오 객체의 프레임 10개가 전송되면 참조 객체 프레임 10개, 즉 참조 객체 5개도 전송된다.
• 이 독립된 프레임들을 반대편 사이트에서 받아 재조립한다.

메시지 우선순위화 및 서버 푸싱

• 메시지 우선순위화(message prioritization) : 요청들의 상대적 우선순위를 조정한다.
• 이 가중치와 프레이밍이 함께 작동하여, 우선순위가 높은 요청을 위한 프레임을 먼저 보낸다.
• 또한 서버는 클라이언트의 특정 요청에 대해 처음 응답 외에도 추가적인 객체를 푸시할 수 있다.
• 서버는 클라이언트가 웹 페이지를 구동하기 위해 필요한 객체들의 요청이 오기도 전에 미리 클라이언트로 보낼 수 있다.
• 따라서 요청의 대한 지연을 없앨 수 있다.

HTTP

• 새로운 트랜스포트 프로토콜인 QUIC는 UDP 프로토콜 위에 위치하는 애플리케이션 계층에 구현되어 있다.
• 아직 표준화 되어있지는 않다.

• Previous
  AWS 백서 : AWS 서비스 알아보기