[네트워크] URI와 웹 브라우저 요청 흐름, HTTP

728x90

URI와 웹 브라우저 요청 흐름, HTTP

URI

웹 브라우저 요청 흐름

HTTP

클라이언트 서버 구조

Stateful, Stateless

비연결성

HTTP 메시지

URI (Uniform Resource Identifier)

- Uniform : 리소스를 식별하는 통합된 방식

- Resource : 자원, URI로 식별할 수 있는 모든 것 (제한 없음) - 실시간 교통 정보 등

- Identifier : 다른 항목과 구분하는데 필요한 정보 - 주민번호 등

URI는 주민번호로 식별하듯이, 자원 자체를 식별하는 방법이고 로케이터, 이름 또는 둘 다 추가로 분류될 수 있다.

- URL : Uniform Resource Locator - (위치) 리소스가 여기 있어요~ (김영한이 여기 살고 있어요~)

- URN : Uniform Resource Name - (이름) 리소스 (김영한 그 자체), 어떤 책은 ISBN

🔆 위치는 변할 수 있지만, 이름은 변하지 않는다.

긍까, 내가 김영한씨의 집주소를 아는 거랑 김영한 씨를 아는 거랑은 다르다.
결국 김영한씨를 찾으려면 집주소를 아는 게 실제 김영한이라는 리소스를 찾는데 더 도움이 된다.

이 뒷부분이 프레그먼트임... ㅇㅇ 그렇대..

웹 브라우저 요청 흐름

1️⃣ 웹 브라우저가 google.com 이라는 DNS 서버를 조회해서 IP 주소를 얻고, port 정보도 (https니까) 443도 얻음

2️⃣ HTTP 요청 메시지를 생성함

HTTP Method + Path + HTTP 버전정보 + host

3️⃣ 3 way handshake (SYN - ACK - SYN/ACK)를 통해 구글 서버와 연결을 확인

4️⃣ Socket 라이브러리를 통해서 데이터를 전달 (그 과정에서 패킷이 TCP(IP(진짜 보낼 HTTP 전송 데이터)) 이렇게 감싸지게 됨)

5️⃣ 인터넷 망으로 던지며 노드를 타고 이동해서 목적지 PORT로 도착

6️⃣ 구글 서버가 TCP/IP 패킷을 까고 HTTP 메시지를 보고 해석

7️⃣ 구글 서버에서 HTTP 응답 메시지를 만들어서 출발지 PORT로 전송

200 OK - 성공

Content-Type: text/html (타입)

charset=UTF-8 (문자셋)

Content-Length: 3423 (길이)

8️⃣ 웹 브라우저가 HTTP 응답 메시지를 받아 내부에 있는 html을 열어서 렌더링~

HTTP HyperText Transfer Protocol

HTTP는 월드 와이드 웹(WWW)에 내재된 프로토콜
HTTP는 인터넷에서 데이터를 주고 받을 수 있는 프로토콜

모든 형태의 데이터를 (Text, HTML, 이미지, 영상, 파일, 음성, JSON, XML 등) HTTP 메시지에 담아서 전송

서버 간에 데이터를 주고 받을 때도 마찬가지!

- 클라이언트 서버 구조를 기반으로 동작

- 무상태 프로토콜을 지향한다. : Stateless

- 비연결성의 특징

- HTTP 메시지로 통신

- 단순하고, 확장 가능하다.

역사를 간단히 읊으면,,,
초창기 1991년에는 GET만 지원했는데 중요한 거는 HTTP/1.1이 제일 중요하고, 이 스펙에 대부분의 기능이 들어있음.
그 후는 성능 개선에 초점이 맞춰져 있다. 1997년에 나왔다가 1999년, 2014년에 개정이 되었다.
RFC7230~7235(2014년 개정)버전으로 공부하는 것이 중요하다..

기반 프로토콜
TCP : HTTP/1.1, HTTP/2
UDP : HTTP/3
현재는 HTTP/1.1을 주로 사용하고 있지만 HTTP/2, HTTP/3도 점점 증가하고 있다.
1.1만 배워두면 2, 3은 성능 개선이라 크게 상관은 없다.
결론 = HTTP/1.1만 잘 알면 된다!

1. 클라이언트 서버 구조

클라이언트가 서버에 요청을 보내면 서버는 그에 대한 응답을 보내는 클라이언트 서버 구조로 이루어져 있다.

클라이언트와 서버 개념을 분리해야 한다. - 독립적!

- 클라이언트 : UI/UX

- 서버 : 비즈니스 로직

클라이언트가 HTTP Method를 통해 서버에게 요청을 보내고, 클라이언트는 서버한테 응답이 올 때까지 대기한다.

서버가 요청에 대한 결과를 만들어서 응답을 한다. (Request, Response 구조)

2. 무상태 프로토콜 Stateless 지향

🔰클라가 요청 시에 애초에 필요한 정보를 다 담아서 요청하기 때문에 서버는 상태를 보관하지 않고, 필요한 값을 응답한다.

1). 상태를 보관/보존하지 않기 때문에 클라이언트를 식별하지 못하는데

- 이벤트 소개 페이지의 경우, 무상태로 설계하고

- 로그인이 필요해서 상태를 유지해줘야 하는 경우,➡️웹(쿠키/세션), 앱(토큰)을 통해서 가능하다.

2). 무상태를 지향하기 때문에 중간에 서버1이 장애가 나면, 중계서버가 2번으로 요청해도, 서버2가 응답을 해줄 수 있다.

어차피 클라이언트가 요청에 정보를 다 가지고 있기 때문에 ➡️ 같은 맥락으로 장애가 아니더라도 응답 서버를 바꿀 수 있다.

3). 결국 각각의 서버는 클라이언트의 요청을 다 알 수 있기 때문에

클라이언트의 요청이 갑자기 증가했을 때 ➡️ 서버의 대거 투입 즉, 무한한 서버 증설이 가능하고, 수평확장 (scale out)에 유리하다.

4). 수평확장에 유리하기 때문에 ➡️ 대용량의 트래픽이 발생해도 어느 정도 커버가 가능하다.

예를 들어, 명절 KTX 예약, 아이유 콘서트 티켓팅 같은 수만명 동시 요청이 발생하는 경우

5). 무상태의 단점으로는, 데이터를 너무 많이 보냄 (필요한 정보를 다 담아서 요청하기 때문)

🔆 결론적으로, 최대한 무상태로 설계하고, 상태 유지는 최소한으로만, 꼭 필요한 경우에만 사용해야 한다.

무상태의 경우)

예를 들어, 서브웨이에 주문을 해
클라이언트(나)가 원하는 샌드위치 상태 : [화이트, 아메리칸 치즈, 올리브+피클 빼기, 소스는 랜치, 양상추 많이]

내가 처음에 알바A한테 내 요청사항을 다 말했음
알바A가 화이트 빵에 치즈 올리고 굽굽하는 동안
알바B가 와서 내 주문을 다시 받아 그러면 어차피 내가 원하는 샌드위치 상태는 내가 알고, 내가 가지고 있기 때문에
문제 없이 끊기지 않고 주문이 완료가 됨

종나 많은 고객이 와도,, 알바생 많이 대거 투입되면 서브웨이는 잘 돌아감..ㅇㅇ
어차피 고객이 주문할 걸 다 생각하고 있기 때문에 (알바생이 고객 한 명 한 명 요청사항을 다 외우고 있지 않는다는 것임)

그 덕에
1. 중간에 알바생이 A->B로 바껴도 상관없음
2. 고객이 엄청 올 경우에, 알바생을 엄청 늘리면 됨
3. 따로, 알바생이 바뀔 경우에 주문내용 알려줄 필요 없음 어차피,, 고객이 알려줌

3. 비연결성 connectionless

- 기본적으로 HTTP는 연결을 유지하지 않는 모델이다.

- 일반적으로 연결은 초 단위의 이하의 빠른 속도로 응답한다.

- 1시간 동안 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작다.

예를 들어, 웹 브라우저에서 계속 연속해서 검색버튼을 누르는 건 아니잖아? 한 번 검색버튼 누르고 웹 둘러보고,,

(검색 후에 계속 서버 연결시켜두는 건 아니고, 이미지 같은 거 보내준 후에 연결 끊고, 그 다음 검색버튼 눌러서 서버 연결 요청 시에 연결하는 것임...)

그래서 연결이 유지되지 않는 것이 서버 자원을 효율적으로 사용하는 것이다.

1). TCP/IP는 연결을 유지하는 모델

클라이언트1은 클라이언트2/3과 서버가 요청-응답을 하는 동안 계속 연결이 유지되는 중이며 그러면 서버 자원이 소모가 된다.

이 경우에, 클라1/2 놀고 있어도 계속 연결해야 한다.

2). TCP/IP는 연결을 유지하지 않는 모델

자원을 현재 요청을 주고 받을 때만 연결하고 끊어서 서버가 유지하는 자원을 최소한으로 할 수 있다.

이 경우에 서버가 동시에 유지해야 하는 최소한의 자원의 크기가 줄어든다.

(한계점)

- 처음 3 way handshake는 있어야 함, 근데 끊고 나서는 다시 또 3 way handshake를 해줘야 하는 단점이 있음 (그 덕에 시간 추가)

- 웹 브라우저가 요청하면 많은 자원을 함께 다운로드해야 함 (html, javascript, image, css 등)

- 연결하고 받고, 끊고의 반복..? -> HTTP의 지속 연결(persistent connections)로 문제를 해결했음

지속 연결은 내부 메커니즘을 통해서 연결을 유지해서 요청 후 다 응답을 받은 후에 연결을 끊는다.

HTTP 메시지

🔰HTTP 메시지를 통해 통신한다.

근데 요청 메시지와 응답 메시지의 구조는 약간 다르다.

HTTP는 단순하다. 메시지도 단순하고...

🔰HTTP 요청 메시지

🔰HTTP 응답 메시지

🔆 지금은 HTTP 시대 🔆