Ch2-2-1) Web and HTTP

2.2 WEB and HTTP

WEB Page들은 Object들로 구성된다.

• 여기서 Object란, 단일 URL로 지정할 수 있는 하나의 파일 (HTML, JPEG img, JS 등)
• 대부분의 WEB Page는, Base HTML-file과 URL로 지정할 수 있는 referenced objects로 구성된다.
  • ex)

  <http://www.school.edu/picture.gif>
  호스트의 이름 : www.school.edu
  경로 이름 : picture.gif
  
  

• HTTP (HyperText Transfer Protocol)이란, Web의 application layer protocol이다.

Web Browser and Client

 

 

• Web 환경에서, 우리는 Web browser와 Web client라는 용어를 동치로 생각하여 사용하게 된다. 이는 Web browser가 HTTP의 클라이언트 축을 구성하기 때문이다.
• 일반적으로, 사용자가 웹 페이지를 요청할 때
  • Browser은 웹 내부에 있는 객체에 대한 HTTP요청 메시지를 서버로 보내고
  • Server은 요청을 수신하고 객체를 포함하는 HTTP 응답 메시지를 보낸다.

→ 그럼, HTTP message의 동작 원리는 무엇일까?

HTTP and TCP

• 우선, 기본적으로 HTTP는 TCP를 전송 프로토콜로 사용한다.
• 다음 4가지 단계를 통해서, Server에 request를 보내고 response를 받게 된다.

1. Client initiates TCP Connection
   • client가 웹 브라우저를 통해 웹사이트에 접속하면, 웹 브라우저는 서버로 TCP 연결을 시도하게 되는데, 이때 웹 서버의 기본 포트번호 80이 사용된다.
2. Server accept TCP connection
3. HTTP messages exchange between browser and Web server
   • HTTP messages (=applicaion-layer protocol) , browser(=HTTP client), Web server(=HTTP server)
   • HTTP는 application-layer의 protocol이기에 실제로 데이터는 TCP connection을 통해 이동한다.
4. TCP connection end

이를 간단하게 정리하면, 아래와 같다.

1. HTTP 클라이언트는 먼저 서버에 TCP 연결을 시작한다.
2. 연결이 이루어지면, 브라우저와 서버 프로세스는 각각의 소켓 인터페이스를 통해 TCP로 접속한다.
3. 클라이언트는 HTTP 요청 메시지를 소켓 인터페이스로 보내고, 소켓 인터페이스로부터 HTTP 응답 메시지를 받는다.
4. 마찬가지로, HTTP 서버는 소켓 인터페이스로부터 요청 메시지를 받고 응답 메시지를 소켓 인터페이스로 보낸다.

→ 이렇게 TCP를 통해서 보내면, 데이터 손실 없이 안정적으로 데이터가 통신 되니, 모든 HTTP 메시지가 정상적으로 이동한다. HTTP는 TCP가 어떻게 데이터 손실을 막고, 데이터를 전송하는지는 알빠노이다.

→ Layer hierarchical architecture의 장점

• 또한, HTTP는 “Stateless”하다.
  • 같은 클라이언트가 몇 초 후에 같은 요청을 보내도 서버는 똑같이 답변해준다.
  • 이 말은, client가 요청한 과거의 request들에 대한 정보를 저장해놓지 않는다
  • 참고로, State를 기억하는 Protocol은 매우 복잡하다.
    • 만약 server와 client가 충돌해 연결이 끊기면, data inconsistency가 발생하기 때문에 문제가 아주 어려워진다.

Non-persistent connection / Persistent connection

1. Non-persistent connection

• 하나의 객체가 전송되면, TCP 연결이 해제되는 것
  • 웹페이지에는 여러개의 객체가 포함될 수 있는데, 이 여러개의 객체마다 새로운 TCP 연결이 필요함.

Ex)

어느 Web client가 Base-HTML file과 10개의 이미지로 구성된 객체를 서버에 요청하는 상황을 생각해보자. 또한, 이 11개의 객체는 같은 서버에 있다고 가정하자. Client는 다음과 같은 URL 주소를 서버에 요청하였다.

www.someSchool.edu/someDepartment/home.index

그럼 연결 수행 과정은 다음과 같다.

1. 먼저, HTTP Client는 , HTTP server(Process)와 TCP 연결을 시작하려 한다.
   • 이때 주소는 www.someSchool.edu이고, Port 번호는 80이다.
   • 그럼, HTTP server도 포트 80에서 client의 요청을 기다리고 있다가, accept한다.
     • 이 과정은 3-hand-shake 과정으로, 추후 설명
2. HTTP client는 TCP connection socket에 URL이 포함된 request message를 집어넣는다.
   • 또한, 메시지에 client가 someDepartment/home.index object를 원한다는 사실도 포함시킨다.
3. HTTP server은 request message를 받고, client가 요청한 객체가 포함된 response message를 TCP connection socket에 넣는다.
4. HTTP server은 socket에 넣고 보냈으니, TCP connection을 닫는다. (실제로는, 클라이언트가 응답 메시지를 받을 때 까지는 닫지 않는다)
5. HTTP client가 응답 메시지를 받으면 TCP 연결이 종료되고, 메시지는 캡슐화 된 객체가 HTML 파일인 것을 나타낸다.
   • 이때 클라이언트는 메시지로부터 파일을 추출하고, HTML을 조사하여 10개의 JPEG object에 대한 참조를 찾는다.
6. 이 10개의 reference object들을 전송받기 위해 1~5의 과정을 반복한다.

→ HTTP는 통신 프로토콜만 구성할 뿐, 웹페이지에 대한 관심은 알빠노라는 것을 알 수 있다.

Note) 참고로, 브라우저는 여러개의 TCP connection을 비동기적으로 (asynchronous) 처리할 수 있어 앞의 단계를 동시에 수행할 지, 순차적으로 수행할 지의 동시성 정도를 설정하여 브라우저를 구성할 수 있다.

• Non-persistent connection을 사용하는 프로토콜에는 HTTP 1.0이 있다.
• 그럼, 이렇게 파일을 요청하고 다시 받을 때까지의 시간을 측정하기 위해, RTT (Rount-trip-time) 이라는 term을 도입해보자.
• RTT란, 패킷이 clinet → server로 가고, server→clinet까지 다시 되돌아오는 데 걸리는 시간이다.
  • RTT는 transmission, queueing, processing delay 등 지연 시간을 포함하는 개념이다.
•  

 

 

 

• 하나의 객체를 받는데 걸리는 시간은, 위의 사진과 같다.

1. 먼저, 초기 TCP connection을 수립하는데 걸리는 시간은 1 RTT이다.
2. 연결이 된 이후, Client가 request를 보내고, response를 받는데 또 1RTT가 소요되고, 이 과정에서 transmission delay가 발생한다.

⇒ Non-persistent HTTP response time =  2RTT+ file transmission  time 임을 알 수 있다.

이러한 Non-persistent HTTP의 단점은 다음과 같다.

1. 1개의 object당 최소 2RTT가 소요된다.
2. TCP connection을 수립하기 위한 OS overhead가 발생한다.
3. browser는 여러개의 reference object를 parallel하게 fetch하기 위해 여러개의 connection을 병렬처리해야한다.

이러한 단점을 보완한 것이 바로 Persistent connection이다.

1. persistent connection

• 하나의 객체가 전송이 완료되어도, 일정 시간동안은 TCP 연결이 해제되지 않는 것
  • 하나의 TCP 연결로 여러개의 객체를 전송할 수 있음.
• EX) HTTP 1.1
• 한번 TCP connection이 성립된 client와 server은 이후 하나의 지속 TCP connection을 통해 request와 response를 주고받는다. → TCP 대기시간 삭제 : 추가적인 RTT 절약 가능
• 이들 객체에 대한 요구는 진행 중인 요구에 대한 응답을 기다리지 않고 연속해서 만들 수 있다. (파이프라이닝, pipelining)
• 일반적으로 HTTP 서버는 일정 기간 사용되지 않으면 연결을 닫는다.

그렇다면, 이렇게 주고받았던 HTTP messages는 어떤 format으로 구성되어 있는지 알아보자.

HTTP message format

• 잘 알다시피, HTTP message의 종류는 2가지로, request와 response이다.

1. Request message format

 

 

• Request message는 ASCII 코드로 이루어져 있다.
• 각 줄은 CR(carriage return)과 LF(line feed)로 구별된다. 마지막 줄에 이어서 CR과 LF가 따른다.
• header line의 마지막 줄에는 \r\n이 2개들어가 있는 것을 확인할 수 있다.

그럼, 이를 일반화 시켜서 general한 format의 request message를 보자.

 

 

• 먼저, 맨 위의 Requset line에 대해서 살펴보자.
  • Request line은 총 3개의 field로 구성되어있다.
  • Method : GET,POST,DELETE 등 처리할 정보에 대한 정보가 담겨있다.
  • URL : HTTP 요청을 보낼 서버의 자원을 의미한다. 보통, 쿼리가 포함된 URI가 명시됨
  • Version : HTTP 버전이 무엇인지 표기된다.
    • Ex) HTTP 버전 1.1은 “HTTP/1.1”로 표기된다
• 그 다음, Header line에 대해서 살펴보자
  • Header line은 0개 이상의 HTTP 헤더가 명시된다. (실제로는 엄청 다양한 HTTP Header 이용)
  • Header line에는 다음과 같은 다양한 정보가 포함된다.
  1. Host
     • 객체가 존재하는 호스트를 명시한다.
     • 이미 호스트까지 TCP 연결이 맺어져 있어 불필요하다고 생각될 수 있지만, 2.2.5절에서 나오는 웹 프록시 캐시에서 필요로 한다.
  2. Connection : 이 헤더 라인을 포함함으로써, 브라우저는 서버에게 지속 연결 사용을 원하는지 비지속 연결 사용을 원하는지 전달한다.
  3. User-agent : 서버에게 요청을 하는 브라우저 타입을 명시한다.
  4. Accept-language : 헤더는 사용자가 객체의 어떤 언어 버전을 원하고 있음을 나타낸다.

Ex)

Host: www.someschool.edu
Connection: close
User-agent: Firefox/118.0
Accept-language: fr

• Entity body
  • request Method에 따라 포함하는 정보가 달라지는 메시지 본문 부분이다.
  • GET일 때는 비어있고, POST 일 때 사용된다.
    • 입력하고자 하는 데이터를 적어 전송한다.

→ 그렇다면, 다양한 종류의 HTTP request messages에 대해 알아보자.

1. POST Method

• 서버로 하여금 특정 작업을 처리하게끔 하는 메서드
• 웹 페이지의 폼 입력과 같이, 사용자가 입력한 데이터를 서버로 전송할 때 사용
• entity body에 입력한 정보가 담겨서 전송됨

 

2. GET Method

• 서버로부터 Resource를 얻고 싶을때 사용하는 메서드
• 데이터를 URL에 포함하여 서버로 전송. 이 예시에서는 ? 뒤에 쿼리 문자열을 포함한 URL이 사용되며, www.somesite.com/animalsearch?monkeys&banana처럼 쿼리 파라미터가 URL의 일부로 전달.
  • 쿼리 파라미터는 reference object를 찾기 위해 사용

3. HEAD Method

• GET Method와 거의 유사하지만,응답 본문 없이 HEADER만 응답받는 메서드
• 파일이나 페이지의 크기 또는 타입 등의 정보를 얻을 때 사용
• → 실제 파일을 다운로드 하지 않고도 파일에 대한 정보를 얻을 수 있음

 

4. PUT Method

• 서버에의 resource를 replace하기 위한 메서드
• 지정된 URL에 존재하는 파일을 완전히 대체하거나, 새로운 파일을 업로드
• POST와 유사한 방식이나, PUT은 요청한 경로에 데이터를 완전이 덮어씌움

 

 

 

 

 

2. Response format

 

 

 

• Response message는, request message와 달리 시작 라인에 “Status Line’이 포함된다.
• 상태 코드의 종류는 다음과 같다.
  • 200 : OK
    • request가 성공했고, 이 message의 뒤쪽에 요청한 object가 포함되어있다.
  • 301 : Move permanently
    • 요청한 객체가 영원히 이동했고 새롭게 이동한 URL이 field에 포함되었다.
  • 400: Bad request
    • 요청이 뭔 개소린지 모르겟다
  • 404 : Not found
    • 요청한 주소로 가보니까 요청한 문서는 내 서버에 존재하지 않는다.
  • 505 : HTTP Version Not Supported
    • 요청 HTTP protocol 버전을 서버가 지원하지 않는다.
• 헤더라인엔 다음과 같은 다양한 정보를 포함할 수 있다. (종류가 많고, 아래는 그 일부이다.)

1. Connection : 클라이언트에게 메시지를 보낸 후 TCP 연결을 닫을지 말지 결정한다.
2. Date : HTTP 응답이 서버에 의해 생성되고 보낸 날짜와 시간을 나타낸다.
3. Server : 메시지가 어떤 웹 서버에 의해 만들어졌는지 나타낸다.
4. Last-Modified : 객체가 생성되거나 마지막으로 수정된 시간과 날짜를 나타낸다.
5. Content-Length : 송신되는 객체의 바이트 수를 나타낸다.
6. Content-Type : 개체 몸체 내부(Entity body)의 객체가 어떤 타입인지 나타낸다.