2. 웹과 HTTP

Reference :
컴퓨터 네트워킹 하향식 접근 [8판] / 퍼스트 북 / James F. Kurose, Keith W. Ross
건국대학교 컴퓨터 네트워크 수업 / 김기천 교수님

HTTP 개요

HTTP
: 웹의 애플리케이션 계층 프로토콜
==> 클라이언트 프로그램 & 서버 프로그램으로 구현됨
==> 서로 다른 호스트에서 수행되는 클라이언트 프로그램과 서버 프로그램은 HTTP를 통해 통신함

웹 용어

- 웹 페이지

• 객체로 구성됨
• 객체 : HTML파일, JPEG 이미지, GIF 이미지, 자바 애플릿, 오디오 클립
• HTML 파일은 페이지 내부의 다른 객체를 그 객체의 *URL로 참조함
• *URL : [객체를 갖고 있는 서버의 호스트 네암] + [객체의 경로 이름] 으로 구성

<aside>
💡 http://www.naver.com/login

</aside>

`www.naver.com`: 호스트 네임

`/login` : 경로 이름

 

- 웹 브라우저

• 인터넷 익스플로러, 파이어폭스

 

- 웹 서버

• 아파치, IIS, nginx

 

HTTP는 TCP를 전송 프로토콜로 사용!

서버(클라) - 애플리케이션 계층 - 소켓 - TCP(트랜스포트 계층)

 

HTTP는 비상태 프로토콜

서버가 클라이언트에게 요청파일을 보낼 때, 서버는 클라이언트에 관한 어떠한 상태 정보도 저장하지 X (그래서 쿠키, 세션을 사용 !)

 

장점

1. 서버 설계를 간편하게 함
2. 동시에 수천 개의 TCP 연결을 다룰 수 있는 고성능의 웹 서버를 개발하도록 해줌

 

단점

1. 서버가 사용자 접속을 제한하거나
2. 사용자에 따라 콘텐츠를 제공할 수 없음

 

---

비지속 연결과 지속 연결

클라이언트-서버의 요구/응답이

분리된 TCP 연결을 통해 보내짐 -> 비지속 연결

같은 TCP 연결을 통해 보내짐 -> 지속 연결 (디폴트 값!)

 

- 비지속 연결 HTTP

각 객체마다 새로운 연결이 있어야 => 객체 개수만큼 TCP 버퍼를 할당해야 함

하나의 객체를 요청하고 응답받을 때마다 3-way handshake를 해야 한다 => 비효율적

하나의 객체에 대한 응답 시간: 2RTT + HTML (객체) 전송시간

 

3-way-handshake

https://seongonion.tistory.com/74

[네트워크] TCP 3-way & 4-way handshake란?

 

- 지속 연결 HTTP

응답을 보낸 후에 TCP 연결을 그대로 유지 => 여러 개의 객체를 하나의 지속 TCP 연결을 통해 보낼 수 있음, *파이프라이닝 기법

 

*파이프라이닝 기법

: 한 번에 하나의 명령어만 실행하는 것이 아니라 하나의 명령어가 실행되는 도중에 다른 명령어를 실행을 시작하는 식으로 동시에 여러 개의 명령어를 실행하는 기법

---

HTTP 메세지 포맷

HTTP 메시지: 요청 메시지 + 응답 메시지

 

- HTTP 요청 메시지

GET /somedir/page.html HTTP/1.1 # request line
Host: www.someschool.edu        # header line 시작
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr             # header line 끝

# body line
....

 

- 특징

1. ASCII로 쓰여 있어서 쉽게 이해가 가능
2. 5줄 (이상)로 구성 & 각 줄은 CR과 LF로 구별됨
3. (CR: 한 줄 쓰고 밑에 줄에 글 쓸 때 오른쪽 -> 왼쪽으로 이동 / LF: 한 줄 아래로 ㄱㄱ)

 

- 요청 라인 (request line)

(method) 필드 + URL 필드 + HTTP 버전 필드로 구성

• method 필드
  • GET, POST, HEAD, PUT, DELETE ...

 

- 헤더 라인 (header line)

Host: www.someschool.edu

• 객체가 존재하는 호스트를 명시
• 웹 프록시 캐시에서 필요로 하는 정보

 

Connection: close

• 지속 연결 사용을 원하지 않는다는 것을 서버에게 알려줌

 

User-agent: Mozilla/5.0

• 서버에게 요청을 하는 브라우저 타입 명시
• 서버가 같은 객체에 대한 다른 버전을 다른 타입의 사용자 에이전트에게 보낼 수 있음

 

Accept-language: fr

• 서버에 해당 언어 버전을 요청

 

- 바디 라인 (body line)

POST 방식에서 사용 (GET 방식에서는 비어있음)

 

HEAD 방식

GET 방식과 유사

서버가 HEAD 방식을 가진 요청을 받으면 HTTP 메시지로 응답

클라이언트가 요청한 객체는 보내지 않음

개발자가 디버깅을 위해 자주 사용

 

PUT 방식

웹 서버에 업로드할 객체를 필요로 하는 애플리케이션에 의해 사용

 

DELETE 방식

사용자/웹 애플리케이션이 웹 서버에 있는 객체를 삭제

 

HTTP 응답 메시지

HTTP/1.1 200 OK             # status line
Connection: close           # header lines 시작
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      # header lines 끝
(data data data data data ...) # entity body

- HTTP/1.1 200 OK

• version 필드 + status 필드 + 상태 메시지

- Connection: close

• 클라이언트에게 메시지를 보낸 후 TCP 연결 끊음

- Date: Tue, 18 Aug 2015 15:44:04 GMT

• HTTP 응답이 서버에 의해 생성되고 서버에서 클라이언트로 보낸 날짜와 시간

- Server: Apache/2.2.3 (CentOS)

• 메시지가 아파치 웹 서버에 의해 만들어졌음을 명시

- Last-Modified: Tue, 18 Aug 2015 15:11:03 GMT

• 객체가 생성되거나 마지막으로 수정된 시간과 날짜
• 로컬 클라이언트와 네트워크 캐시서버에서 객체 캐싱에 중요한 역할을 함

- Content-Length: 6821

• 송신되는 객체의 바이트 수

- Content-Type: text/html

• entity body가 HTML 텍스트인 것을 나타냄

 

상태 코드

• 200 OK
  • 요청 성공 & 정보가 응답으로 보내짐
• 301 Moved Permanently
  • 요청된 객체가 이동됨
  • 새로운 URL은 응답 메시지의 Location: 헤더에 나와있음
• 400 Bad Request
  • 서버가 요청을 이해할 수 없다
• 404 Not Found
  • 요청 문서가 서버에 존재 X
• 505 HTTP Version Not Supported
  • 요청 HTTP 프로토콜 버전을 서버가 지원 X

 

HTTP 응답 메시지 보는 방법

telnet gaia.cs.umass.edu 80
GET /kurose_ross/interactive/index.php HTTP/1.1
Host: gaia.cs.umass.edu

 

---

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

비상태 프로토콜인 HTTP의 한계점을 보완하기 위해 쿠키를 사용함

 

쿠키 구성 요소

1. HTTP 응답 메시지 쿠키 헤더라인
2. HTTP 요청 메시지 쿠키 헤더라인
3. 사용자의 브라우저에 사용자 종단 시스템과 관리를 지속시키는 쿠키 파일
4. 웹 사이트의 벡엔드(back-end) 데이터베이스

 

상태

1. ebay 사이트에 방문한 적이 있음
2. amazon 사이트에는 방문한 적이 없음

 

과정

1. 특정 웹 사이트(amazon)에 처음 방문 ⇒ 서버에서 쿠키를 생성하여 클라이언트로 전달
2. HTTP 응답메시지 Set-Cookie: 1678
3. 클라이언트(브라우저)는 관리하는 특정한 쿠키 파일에 Set-Cookie:를 덧붙임
4. 이때, 서버의 호스트네임과 Set-Cookie 헤더와 식별번호를 포함
5. amazon 웹 사이트에서 다른 요청을 할 때마다 브라우저는 쿠키 파일을 참조하고 식별번호를 발췌하고 HTTP 요청에 식별번호를 포함하는 쿠키 헤더 파일을 넣는다

 

설명

amazon은 “쇼핑카트” 기능을 제공하기 위해 쿠키를 사용한다

---

웹 캐싱

웹 캐시 (Web cache, 프록시 서버 (proxy server))

: 기점 웹 서버(origin Web server)를 대신하여 HTTP 요구를 충족시키는 네트워크 개체

=> 자체의 저장 디스크를 갖고 있어 최근 호출된 객체의 사본을 저장 및 보존

=> 객체에 대한 각각의 브라우저 요청은 프록시 서버에 가장 먼저 보내진다

 

과정

1. 브라우저는 웹 캐시와 TCP 연결을 설정하고 웹 캐시에 있는 객체에 대한 HTTP 요청을 보낸다
2. 웹 캐시는 객체의 사본이 자기에게 저장되어 있는지 확인한다.
3. 만일 저장되어 있다면 웹 캐시는 클라이언트 브라우저로 HTTP 응답 메세지와 함께 객체를 전송한다
4. 만약 웹 캐시가 객체를 갖고 있지 않다면, 웹 캐시는 기점 서버인 www.someschool.edu로 TCP 연결을 설정한다. 그러고 나서 웹 캐시는 캐시와 서버 간의 TCP 연결로 객체에 대한 HTTP 요청을 보낸다. 이러한 요청을 받은 후에 기점 서버는 웹 캐시로 HTTP 응답 메시지와 함께 객체를 보낸다
5. 웹 캐시의 객체를 수신할 때, 객체를 지역 저장장치에 복사하고 클라이언트 브라우저에 HTTP 응답 메세지와 함께 객체의 사본을 (클라이언트 브라우저와 웹 캐시 사이에 이미 설정된 TCP 연결을 통해) 보낸다.

💡 캐시는 서버이면서 클라이언트이다!

 

활용

대학교는 캠퍼스 네트워크에 웹 캐시를 설치하고 모든 캠퍼스의 브라우저가 이 캐시로 요청을 보내도록 설정함

 

장점

1. 클라이언트의 요구에 대한 응답 시간을 줄일 수 있음
2. 한 기관에서 인터넷으로 접속하는 링크상의 웹 트래픽을 대폭으로 줄일 수 있음

 

추가설명

'인터넷 지연'

: 접속회선의 인터넷 부분 라우터가 HTTP 요청을 전달하고 응답을 받을 때까지의 시간

 

총 응답 시간=LAN 지연 + 접속 지연 + 인터넷 지연

 

LAN 트래픽 강도

(15요청/초)*(1Mbit/요청)/(100Mbps)=0.15

 

인터넷 트래픽 강도(접속 회선 사이)

(15요청/초)*(1Mbit/요청)/(15Mbps)=1

 

문제

트래픽 강도가 1에 가까워지면 회선의 지연은 매우 커지고 한없이 증가함

(TMI: 일반적으로 0.8 미만의 트래픽 강도는 작은 지연에 속한다)

 

해결

1. 접속률을 15Mbps에서 100Mbps로 늘림
2. ⇒ 많은 비용
3. 접속 회선을 증설하지 않고 기관 네트워크에 웹 캐시를 설치
4. 캐시가 만족시키는 요청비율: 0.2~0.7
5. 캐시로 처리(빠른처리): 40%, 나머지 60%는 원출처 서버에 의해 만족되어야 함
6. BUT 이것은 해결책1 보다 확실히 지연속도가 줄어듦⇒ 웹 캐시를 구입해야 하지만 저렴함
7. ⇒ BUT 캐시에 저장된 정보가 최신의 것이 아니라는 새로운 문제 야기

- 조건부 GET

해결책2 문제의 해결

HTTP는 모든 객체들이 최신의 것임을 확인하면서 캐싱하기 때문에 괜찮다(조건부 GET)

 

조건

1. GET 방식 사용
2. If-Modified-Since: 헤더라인을 포함

 

과정

1. 브라우저의 요청을 대신해 프록시 캐시는 요청 메시지를 웹 서버로 보낸다
2. GET /fruit/kiwi.gif HTTP/1.1 Host: www.naver.com
3. 웹 서버는 캐시에게 객체를 가진 응답 메시지를 보낸다
4. HTTP/1.1 200 OK Date: Sat, 3 Oct 2015 15:39:29 Server: Apache/1.3.0 (Unix) Last-Modified: Wed, 9 Sep 2015 09:23:24 Content-Type: image/gif (data data data data data ...)
5. 캐시는
6. 요청하는 브라우저에게 객체를 보내주고
7. 자신에게도 객체를 저장한다
8. 일주일 후에 다른 브라우저가 같은 객체를 캐시에게 요청하면 여전히 저장되어 있다.
9. GET /fruit/kiwi.gif HTTP/1.1 Host: www.naver.com If-modified-since: Wed, 9 Sep 2015 09:23:24
10. 브라우저는 조건부 GET으로 갱신 조사를 수행한다조건부 GET에 대한 응답으로 웹 서버가 여전히 응답 메시지를 보내지만 응답 메시지에 요청된 객체를 포함하지 않음을 볼 수 있다.특히 그 개체가 크다면 사용자가 느끼는 응답 시간이 증가된다
11. 마지막 메시지 HTTP/1.1 304 Not Modified는 클라이언트에게 요청 객체의 캐시된 복사본을 사용하라는 것을 의미한다
12. 요청 객체를 포함하는 것은 대역폭을 낭비하는 것이고,
13. HTTP/1.1 304 Not Modified Date: Sat, 10 Oct 2015 15:39:29 Server: Apache/1.3.0 (Unix) (empty entity body)

---

HTTP/2

- HTTP/2

• 2015년에 표준화된 HTTP/2[RFC 7540]는 1997년에 표준화된 HTTP/1.1 이후 새로운 첫 번째 HTTP 버전이다.

 

 

- HTTP/2 프레이밍

• HOL 블로킹 문제의 해결책으로 등장한 HTTP/2는 각 메시지를 작은 프레임으로 나누고, 같은 TCP 연결에서의 요청과 응답 메시지를 인터리빙한다.
• HTTP 메시지를 독립된 프레임들로 쪼개고 인터리빙하고 반대편 사이트에서 재조립하는 것이야말로 HTTP/2의 가장 중요한 개선점이다

 

 

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

• 메시지 우선순위화 (message prioritiztion)는 개발자들로 하여금 요청들의 상대적 우선순위를 조정할 수 있게 함으로써 애플리케이션의 성능을 최적화할 수 있게 해준다.

 

- HTTP/3

• 새로운 프로토콜인 QUIC와 UDP 프로토콜 위에 위치하는 애플리케이션 계층에 구현되어 있다.
• HTTP/3 : QUIC 위에서 작동하도록 설계된 새로운 HTTP 프로토콜이다