[네트워크] Ch2 - Web과 HTTP

[네트워크] Ch1 - 인터넷과 프로토콜, network edge

[네트워크] Ch1 - Delay, loss, throughput in networks, Protocol layers, service models, Networks under attack: security, Internet history

[네트워크] Ch2 - 네트워크의 원리 및 Application Layer

---

✨ 2.2.1 Web and HTTP

📌 Web and HTTP

웹을 위해서 만들어진 프로토콜이 HTTP이다.

• 웹 페이지는 objects로 구성되어 있고, 오브젝트는 HTMP file, JEPG image, Java applet, audio file와 같은 것들을 말한다.
• 웹 페이지를 크게 봤을 때, 웹 페이지의 큰 틀을 담은 base HTML-file과, 이를 구성하는 referenced objects들로 구성되어 있다.
• 각 오브젝트들은 URL로 addressable하기 때문에 referenced objects라고 칭한다.

📌 HTTP overview

HTTP : hypertext transfer protocol

위와 같은 의미를 가지지만 Web을 위해 디자인된 application layer protocol이다.

Client-Server Model에서 생각하기

- client/server model에서, client는 HTTP protocol을 이용해서 reuqest하고 receives하여 Web object를 표시할 수 있는 browser를 말한다.

- server는 HTTP protocol을 이용해서 requests에 대한 응답으로 object를 보내준다.

즉, client인 browser가 HTTP protocol을 이용하여 server에 요청을 보내고, 서버도 이를 동일한 형식으로 받아서 동일한 HTTP protocol을 통해 응답을 보낸다. 이를 받아서 browser가 화면에 웹 페이지를 표시하는 것이다.

 

브라우저의 종류는 여러가지이지만, 동일한 HTTP protocol을 이용해서 소통하기 때문에 서버와 소통할 수 있다.

✅ HTTP와 TCP의 관계

Application Layer인 HTTP Protocol은 transport layer인 TCP에게 transport를 부탁한다.

HTTP가 서포트하는 메인 어플리케이션이 웹이고, 웹에서는 data integrity가 중요하기 때문에 TCP를 사용하는 것이다.

 

✅ TCP의 역할

TCP는 커넥션을 맺어야 하기 때문에, 클라이어트에서 서버에게 먼저 initiate를 한다. 서버의 IP 주소와 port 80이라는 번호를 이용해서 서버는 이러한 요청을 받아 connection을 맺는다.

커넥션이 완성되고 HTTP 메시지가 browser와 web server 사이에서 교환된 바로 다음 순간, TCP connection이 닫힌다.

 

⭐ HTTP는 stateless하다?

유저가 이전에 보낸 리퀘스트가 무엇이었는지 전혀 기억하지 않는다는 것이다. 만약 프로토콜이 stateful하려면 굉장히 복잡해진다. request history를 어딘가에 저장해야 하고, 크래쉬가 발생할 경우 서버와 클라이언트의 뷰를 일치시키는 데에 많은 오버헤드가 든다. 따라서 stateless하게 사용한다.

📌 HTTP connections를 기준으로 한 HTTP의 분류

✅ non-persistent HTTP

서버에서 업데이트를 하나만 보내줘도 자동으로 TCP connection을 닫는다.

웹 페이지가 여러 오브젝트로 구성되어도, 오브젝트가 10개이면 TCP connection을 10번 맺어야 한다.

초기 HTTP 버전인 1.0 버전에서 사용했다고 한다.

 

✅ persistent HTTP

한 번 커넥션을 맺고, 이를 통해 여러 object를 교환할 수 있다.

현재 HTTP 버전인 1.1 버전에서 지원하고, 대부분의 HTTP가 이 방식을 사용한다.

1️⃣ Non-persistent HTTP

1. HTTP클라이언트는 TCP 커넥션을 맺자고 HTTP server에 요구한다.
2. HTTP 서버는 프로세스가 항상 실행중이고, server host가 켜져있고 server process는 대기 상태를 유지한다. port 80이 오면 이를 accepts하고, 클라이언트에게 알린다.
3. HTTP 클라이언트가 request message를 URL를 담아서 TCP connection socket에 보내고, 메시지는 클라이언트가 object를 원한다는 것을 나타낸다.
4. HTTP 서버가 메시지를 받고, 요청된 object를 담은 response message를 형성하고 socekt에 보낸다.
5. 바로 HTTP server가 TCP connection을 닫는다.
6. HTTP 클라이언트는 response message를 받아서 여기에 포함된 base html file을 이용하고 html을 보여준다. 만약 html file을 파싱하면서, 10개의 referenced jpeg objects를 가지고 있다는 것을 알게 된다.
7. 각 object를 위해 10번의 과정을 반복한다.

⁉️ Response time - RTT란? ⁉️

유저가 URL을 타이핑하고 리턴하고, 메시지가 팝업될 때까지의 딜레이를 말한다.

RTT(definition) : Round-Trip-Time - 아주 작은 패킷이 클라이언트에서 서버로 갔다가 클라이언트로 돌아오긱까지 걸리는 시간. RTT라는 단위 개념을 통해 네트워크의 응답 시간을 표현할 수 있다.

⭐ RTT를 통한 reponse time 표현의 예시

1. TCP 커넥션을 initiate하는 데에 one RTT가 걸린다.
2. HTTP request와 HTTP response에서 one RTT가 걸린다.
3. 그리고 이에 대한 response를 줄 때 file transmission time이 소요된다.
4. 따라서 non-presistent HTTP의 response time은 2RTT + file transmission time이 걸린다고 할 수 있다.

2️⃣ Persistent HTTP

✳️ non-persistent HTTP의 문제점들

• 하나의 object에 2 RTT가 소요된다.
• 속도 향상을 위해 브라우저는 referenced objects를 한 번에 여럿 fetch하기 위해 parallel TCP connections을 요청할 수 있다.
• 그러나 OS는 각 TCP connection을 관리하는 데에 overhead를 가지게 된다. 이러한 overHead를 해결할 필요가 있다.

✳️ 그래서 Persistent HTTP는!

• 서버는 response를 보낸 후에 connection을 남겨둔다.
• 같은 클라이언트/서버의 추가적인 HTTP messages가 동일한 connection을 통해 이동한다.
• cliet는 referenced object를 보자마자 요청한다.
• 모든 referenced objects에 대해 one RTT 정도만 든다.

📌 HTTP request message

이번에는 HTTP Protocol에서 전달되는 메시지의 정해진 두가지 형태에 대해 알아보자.

HTTP는 두 종류의 메시지를 사용한다 : request, response

1️⃣ HTTP requst message

✅ 공통적인 구조

• start Line : 말 그대로 시작하는 라인이다.
• Headers : 해당 리퀘스트의 추가 정보를 담고 있다.
• Body : 리퀘스트의 실제 메세지, 내용을 담지만 Body가 없는 것도 많다.

✅ 첫 줄은 request line으로 구성된다.

• 구성 요소 : GET이라는 metohd / request에서 원하는 파일의 URL / HTTP client가 사용하는 HTTP 의 버전

✅ 그 아래에는 headers line들이 나온다.

• Host에는 HTTP server의 이름을 준다.
• User-Agent : HTTP client의 버전을 준다.
• Accept-Language : 언어를 보내서 원하는 언어로 사용된 버전을 받는다.
• Keep-Alive : TCP connection을 persistent하게 유지해달라는 것
• 마지막에는 carriage return 또는 body가 있는 경우도 있다.

⁉️ HTTP request message의 geeral form ⁉️

2️⃣ Uploading form input

✅ POST method

웹 페이지는 종종 form input을 포함한다

input이 entity body 를 통해 upload된다.

✅ URL method

GET을 사용해서도 upload를 할 수 있다.

request line의 URL 필드에다가 input이 업로드된다.

3️⃣ Method types

✅ HTTP 1.0

• GET
• POST
• HEAD : 서버에게 request에 담은 object를 보내지는 않아도 된다고 하는 것. response는 오지만 object는 오지 않는다.

✅ HTTP 1.1

• GET, POST, HEAD 외에 아래 두 가지 method가 추가되었다.
• PUT : 서버의 URL에 클라이언트가 파일을 업로드하는 것이다.
• DELETE : URL 필드에 있는 특정한 파일을 삭제한다.

📌 HTTP response message

1️⃣ HTTP Response Message의 형태

▶️ 공통적인 구조

• status Line : 리스폰스의 상태를 나타낸다.
• Headers
• Body

서버의 HTTP 버전을 표시하고 status code 및 status phrase를 준다.

날짜를 주고, 서버가 사용하는 프레임워크를 보여주고, 마지막 변경 일자를 알려준다.

Connection도 request와 마찬가지로 유지하도록 만드는 Keep-ALive이다.

2️⃣ HTTP response status codes

• 200 OK : response가 성공했다는 것.
• 301 Moved Permanently : 해당 URI가 다른 주소로 바뀌었을 때 보내지는 코드이다.
• 400 Bad Request : 리퀘스트 메시지가 잘못되어, 이해할 수 없다는 것.
• 401 Unathorized : 유저가 해당 요청을 진행하기 위해 로그인 및 회원 가입이 필요하다는 것을 알리는 것. 예를 들어 토큰이 만료되면 보내진다.
• 404 Not Found : 리퀘스틑 잘 왔지만, 해당 리퀘스트가 서버 document에서 찾을 수 없는 것. 요청된 uri가 존재하지 않는다는 것이다.
• 500 Internal Server Error : 서버에서 에러가 났을 때 사용되는 코드이다.
• 505 HTTP Version Not Supported