How HTTP request works

Internet browser

What happens when you enter www.google.com in brower?
브라우저에 www.google.com 을 치게되면 무슨 일이 일어나는가?

이 글에서는 HTTP의 구조를 가볍게 살펴본 후, 웹개발 실무 면접에서 가장 많이 물어보는 핵심질문 중 하나인 HTTP 요청이 어떻게 처리되는지 정리해보자.

---

HTTP Request & Response

Image from varnish software

클라이언트(browser)에서 HTTP 프로토콜을 통해 서버에 요청(request)을 하면 그에 맞는 리소스를 응답(response)하는 구조는 검색을 통해 많이 알고 있을것이다.

실제로는 위 그림처럼 단순한 연결이 아닌, 수많은 인터넷 망을 거쳐 요청/응답이 이루어진다.

인터넷은 망구조로 되어 있으며, 클라이언트와 서버 사이에는 수 많은 네트워크 장비가 존재한다.

가정집에서 사용하는 모뎀, 공유기(라우터)부터 ISP(SKT,KT,LGU+), 그리고 우리가 자주 사용하는 서비스(Google, 네이버, 카카오 등)의 서버와 네트워크 장비들.. 정말 많다..😇

 

HTTP 구조

OSI 7 Layer

HTTP 는 OSI 7 layer 에서 Application layer에 해당하는 프로토콜로, WWW(World Wide Web)을 위한 데이터 통신에 쓰이며 TCP/IP 프로토콜 위에서 작동한다.

그림의 흐름을 보면 7 계층에서 데이터를 주고 받을 때, 각 계층을 거쳐 데이터가 오가는 것을 볼 수 있다.
자세한 과정과 다른 계층의 정보는 스킵..😇😇

 

HTTP Request&Resposne 구조 from  mozilla

HTTP request 와 response에는 start line header empty line message body 의 구조로 이루어져있다.

범주명은 같지만, request/response 에 따라 정보가 조금씩 다른걸 볼 수 있다. 어떤 정보가 있는지 간단히 정리한다.

 

— Mozilla Link: HTTP 헤더 — HTTP | MDN (mozilla.org) —
Request: client -> server

start line
- HTTP Method: GET POST PUT PATCH DELETE 와 같은 요청 메소드
- Request target: 해당 request가전송되는 목적지 URI
- HTTP Version: HTTP 버전으로HTTP/1.1 HTTP/2 HTTP/3 등 있음. HTTP/1.1 주로 쓰임
header
- Host: 요청이 전송되는 Host URL (ex: google.com, naver.com)
- User-Agent: 클라이언트의 정보 (OS, 브라우저 등 정보)
- Accept: 해당 request가 받을 수 있는 응답 유형; MIME types (mozilla.org)
- Authorization: JWT, ID/PW와 같이 HTTP 인증필요 시 인증정보
body
HTTP Method가 POST PUT PATCH DELETE 에 해당하는 경우, 서버에 특정 정보를 전달할 때 쓰임

— — — — — — — — — — — —
Response: server -> client

start line
- HTTP Version: HTTP/1.1 HTTP/2 HTTP/3 . request의 HTTP Version과 동일
- Status Code: 서버가 클라이언트에게 올바른 처리가 되었는지 명시하는 상태코드 (HTTP 상태 코드 — HTTP | MDN (mozilla.org)
- Status Text: status code에 따른 응답 상태를 명시하는 텍스트.
header
- Server: 서버에 사용된 소프트웨어 정보
- Date: response가 발생된 일시
- Content-Type: response의 리소스 미디어 타입
body
response로 전달되는 데이터 값 (HTML, JSON 등)

많은 정보가 쓰여 있지만, 간단히 설명하자면
HTTP 에서 request&response 전달 과정에서 위의 정보를 참고하여 클라이언트와 서버가 서로 올바른 데이터를 주고 받는게 가능하다.

 

✍️ 위 내용은 정리차원에서 넣어둔거라 스킵해도 무관!

---

The Body

브라우저에 www.google.com 를 입력하면 무슨 일이 일어나는가?

순서 설명에 앞서 DNS에 대해 간략히 소개하자면,
DNS(Domain Name System)은 URL과 이에 상응하는 IP를 저장한다. 각 URL에 맞는 IP는 컴퓨터에 할당되며, 이 IP로 요청을 보낸다. www.google.com 에 맞는 주소가 172.217.175.46 이라고 가정하자. (옆 IP는 slookup google.com결과값)

실제로 브라우저에 www.google.com 또는 http://172.217.175.46 를 입력하면 같은 구글 페이지로 이동하는 걸 확인할 수 있다.

DNS는 전화번호부에서 ‘이름->전화번호’ 를 찾는것처럼 ‘도메인명->IP’ 를 찾는다.

덕분에 서비스의 홈페이지 IP를 외우지 않고, 이름만으로 액세스가 가능하다.

 

본론으로 돌아와서.. 어떤일이 일어나는지 순서대로 설명해보자면,

 

1. 브라우저 주소창에 www.google.com URL을 입력

 

2. cache를 통해 www.google.com 에 해당하는 IP 주소가 있는지 확인한다.

 

I. 가장먼저, 브라우저의 cache를 확인한다. 브라우저에는 이전에 방문한 사이트에 대해 DNS record를 저장하기 때문에, 여기로 가장 먼저 DNS query를 보낸다.

DNS query는 여러 DNS 서버에 검색을 통해 웹사이트의 IP 주소를 불러오기 위해 쓰인다. 이러한 검색을 recursive search라 하며, 원하는 결과를 얻어오거나 없는 경우 에러를 반환한다.

II. 브라우저에 정보가 없을 경우, system call을 통해 OS cache를 확인한다.

브라우저의 DNS record와 별개로 OS에서도 DNS record는 별개로 존재하기 때문

( Linux는 /etc/hosts , Windows는 C:\windows\system32\drivers\etc\hosts 에 저장)

 

III. OS에 정보가 없으면, 도메인의 IP를 얻기 위해 DNS request를 보낸다. 라우터에도 DNS 정보를 담고 있기 때문에, 가장먼저 라우터에 정보를 요청한다.

 

3. cache에 저장된 URL 정보가 없으면, ISP DNS 서버에서 DNS query를 보내어 URL에 해당하는 서버 IP 주소를 불러온다.

라우터에 정보가 없으면, 각 ISP(SKT, KT, LGU+)마다 존재하는 DNS 서버(DNS recursor)로 요청을 보내 cache된 정보를 받아온다.

 

우리가 사용하는 URL은 top-level, second-level, thrid-level 도메인으로 되어있으며,

DNS lookup 과정에서 각 레벨 도메인과 일치하는 서버로 요청을 보낸다.

 

Domain Name System Explained (webhostinggeeks.com)

예제로 구글맵 도메인maps.google.com 에 접속하는 경우, .com도메인 서버(TLD)로 요청을 보내고,

TLD에서 google.com 네임서버로 redirect 시킨다.

여기서 DNS record속 maps.google.com 에 맞는 IP 주소를 DNS recursor가 받아 요청한 브라우저로 반환한다.

만약.net .org 등 다른 도메인의 경우, 그에 맞는 도메인 서버로 요청을 보내어 쿼리를 보내게 된다.

 

4. 전달받은 정보로 서버와 TCP connection을 진행한다.

위 과정을 통해, 요청할 서버의 IP가 브라우저로 전달되었다.

여러 프로토콜이 존재하지만 보통 브라우저는 HTTP를 사용하며,

HTTP는 TCP/IP 위에서 가동되기 때문에 서버와 TCP connection을 이룬다.

 

먼저 TCP connection establish를 위해, Three-way-handshake를 진행한다.

The TCP/IP Guide — TCP Connection Establishment Process: The “Three-Way Handshake” (tcpipguide.com)

Three-way-handshake는 PC 간 통신을 위해 서로 데이터를 보낼 때 순서를 맞추기 위한 Sequence number 를 주고 받는다.

이 과정에서 SYN (synchronize), ACK (acknowledge) 플래그 값을 서로 전달하여 연결을 성립한다. 순서는 아래와 같다.

 

1. 클라이언트가 SYN패킷을 서버로 보내어 새로운 connection 요청을 보낸다.
2. 서버가 포트가 열려 있는 상태에서 방화벽 제한이 없는 클라이언트인지 확인 후 새로운 connection을 생성한다. 그리고 클라이언트가 보낸 SYN패킷에 대한 SYN/ACK 패킷을 반환한다.
3. 클라이언트가 SYN/ACK 패킷을 받으면, 서버에게 제대로 수신한 의미로 ACK 패킷을 전송한다.

위 과정에서 SYN ->SYN+ACK ->ACK 순으로 패킷을 주고 받는다 정도로 이해해도 괜찮다.

 

5. 클라이언트에서 서버로 HTTP 요청을 보낸다.

TCP connection이 이루어진 순간부터 클라이언트와 서버는 데이터 전송이 가능하다.
실제 CRUD 요청 이전에 서버로 HTTP OPTIONS 요청을 보내 요청가능한 HTTP method를 확인한다.

 

이제 실제 리소스 요청이 가능한 상태에서 www.google.com 로 GET 요청을 보내어 URL에 맞는 웹 페이지를 불러올 뿐 아니라,

POST 요청을 통해 서버에 전달할 수 있다.

각 웹 서비스가 구현된 기능에 따라 여러 요청이 가능하고 필요 시 HTTP에 추가 정보를 전달 할수도 있다.

위 HTTP 구조의 정보를 전달하여 로그인, 파일 요청, 연결유지 등 여러 요청이 가능하다!

 

6. 서버가 전달받은 HTTP 요청에 대한 response을 반환한다.

Apache, Nginx 등 웹서버가 설치된 서버는 클라이언트로 받은 요청을 request handler로 전달하고 이에 맞는 response를 생성하는데, 이 부분에서 Java, Python, PHP, Ruby 등 언어와 Spring, Django, Laravel, RoR 과 같은 프레임워크로 개발한 Web Application이 쓰인다.

그렇게 서버에서 받은 요청을 처리하고 HTML, XML, JSON 등 포맷으로 데이터를 HTTP response로 반환한다.

 

7. 클라이언트에서 브라우저로 response에 맞는 정보를 보여준다.

이제 서버로부터 받은 response를 브라우저에 띄워준다. 만약 HTML 파일을 받을 경우,

HTML skeleton을 먼저 렌더링 후, 태그 속 미디어, CSS, JS 파일 등을 가져와 브라우저에서 보여줄 것이다.

마지막으로 google.com 에 맞는 페이지가 브라우저 띄워진다!

Google 페이지를 불러오는데 불과 몇 초 동안 위 과정이 이루어진다

---

위 과정을 한 그림으로.. (by  howstuffworks )

위 과정 또한 네트워크 연결 과정을 생략한 설명이다. 우리가 사용하는 모든 기능에는 추상화 되어 처리되는 만큼 이런 기술적인 과정을 이해하는 기회를 앞으로도 가졌으면 한다 🔚

 

참고 URL
What Happens When You Type google.com Or Any Other URL In Your Browser And Press Enter (linkedin.com)
What happens when you type a URL in the browser and press enter? | by Maneesha Wijesinghe | Medium

 

---

Add-on

위 과정에서 TCP 연결을 위해 쓰이는 Three-way handshake 말고 Four-way handshake도 간단히 적어본다.

Three-way handshake는 클라이언트와 서버의 TCP 연결 성립을 위해 쓰이며,

Four-way handshake는 위에서 성립된 TCP 연결을 해제할 때 쓰인다. 그림과 순서를 보자.

The TCP/IP Guide — TCP Connection Termination (tcpipguide.com)

1. 클라이언트가 서버에게 연결종료를 의미하는 FIN 플래그를 전송한다.
   클라이언트: LAST-WAIT
2. 서버가 요청을 확인하고, 클라이언트에게 ACK 플래그를 보내고, 앱에게 종료 호출 후, 앱 상태를 대기한다.
   서버: CLOSE-WAIT
3. 클라이언트가 서버가 먼저 보낸 ACK 요청을 받고, 서버가 종료될 때까지 대기한다.
   클라이언트: LAST-WAIT
4. 서버 앱이 종료되면 클라이언트에게 연결 종료를 알리기 위해 FIN 플래그를 보낸다.
   서버: LAST-ACK
5. 클라이언트가 서버로부터 FIN 플래그를 전달 받으면, 확인했다는 ACK 플래그를 보낸다.
   클라이언트: TIME-WAIT
6. 클라이언트와 서버 모두 연결 종료된 상태를 확인하고 연결을 닫는다.
   클라이언트&서버: CLOSED

위 과정에서 연결 종료 이후에 데이터가 도착하는 경우는 어떻게 처리될까?

 

4번에서 서버가 보낸 FIN 플래그보다 이전 전송된 패킷이 늦게 도착할 경우(라우팅 지연, 패킷 유실, 재전송 이슈 등),

해당 데이터 패킷은 drop 처리되어 패킷유실이 발생할 수 있다.

이를 위해, 클라이언트는 서버로부터 FIN 플래그를 받아도 MSL 시간(기본 240초)동안 세션을 남겨두어

뒤에 도착하는 패킷을 처리한다. 이 상태가 TIME_WAIT 이고, 시간이 지나면 CLOSED 로 전환된다.