Spring & SpringBoot

HTTP 웹 기본 지식 (1) - 인터넷 네트워크, 웹 브라우저 요청 흐름, HTTP 기초

유자바 2024. 8. 23. 00:21

1. 인터넷 네트워크

IP (Internet Protocol)

  • 역할: 패킷(Packet)이라는 통신 단위로 지정한 IP 주소에 데이터를 전달하는 역할을 수행한다.
  • 과정
    • 클라이언트는 패킷(출발지 IP, 목적지 IP, 데이터, 그 외)을 꾸려 인터넷에 전달한다.
    • 패킷은 인터넷상의 노드를 거쳐 목적지 IP를 가진 서버에 도달한다.
    • 서버가 패킷을 잘 전달받으면 패킷(출발지 IP, 목적지 IP, 상태, 그 외)을 클라이언트에게 전달한다.
    • 패킷은 인터넷 상의 노드를 거쳐 클라이언트에게 전달되는데 이때 클라이언트에서 서버까지의 도달했던 경로와 다른 경로로 클라이언트에게까지 전달될 수 있다.
  • 한계
    • 비연결성: 패킷을 받을 대상 서버가 서비스 불능 상태여도 패킷을 전송한다.
    • 비신뢰성
      • 패킷 소실: 클라이언트가 서버로 인터넷을 통해 패킷을 전송했는데, 중간에 있는 노드에서 패킷이 소실될 가능성이 있다.
      • 패킷 전달 순서 문제: 여러 패킷을 한 번에 전송할 때, 전송했던 순서와 다르게 서버에 도착할 가능성이 있다.

 

해당 문제를 해결하기 위해 나온 것이 TCP, UDP 개념이다.

TCP, UDP를 알아보기 전 인터넷 프로토콜 스택의 4 계층을 먼저 살펴보겠다.

 

인터넷 프로토콜 스택

애플리케이션 계층 HTTP, FTP 어떤 데이터를 주거나 받기 위한 서비스를 정의하는 계층
전송 계층 TCP, UDP 데이터 전송의 신뢰성을 보장하기 위한 계층
인터넷 계층 IP 패킷이 어떤 라우터를 거쳐 전달되는지 결정하는 계층
네트워크 인터페이스 계층 Ethernet 인접한 노드로 패킷을 보내기 위한 역할을 하는 계층으로 프레임(frame)이라고 하는 패킷을 만들어 인터넷망에 전송

출처: [네트워크] 프로토콜 스택(protocol stack)이란?

 

 

TCP (Transmission Control Protocol)

  • 역할: 데이터 전송 시 신뢰성을 보장하기 위해 약속해놓은 규범
  • 특징
    • 3-way handshake
      • 클라이언트와 서버는 SYN, SYN+ACK, ACK 과정을 거쳐 연결을 확인한다.
      • 가상 연결이 완료되었음을 확인하면 데이터를 전송하기 시작한다.
    • 데이터 전달 보증
      • 클라이언트가 서버에 데이터를 전송했을 때 서버는 데이터를 잘 받았음을 응답한다.
      • 만약 서버에서 응답이 없다면 데이터가 제대로 전송되지 않은 것이다.
    • 순서 보장
      • 클라이언트에서 서버로 데이터가 전송되었을 때, 서버 내부적으로 패킷에 포함된 순서 정보를 통해 패킷 순서를 추적하고 패킷의 순서가 잘못되었으면 해당 패킷부터 다시 보내라고 클라이언트에 요청한다.
      • 예를 들어 클라이언트는 패킷1, 패킷2, 패킷3 순서로 전송했지만, 서버에 패킷1, 패킷3, 패킷2 순서로 전달되었으면 서버는 클라이언트에게 패킷2부터 다시 보내달라는 요청을 하게 된다.

 

UDP (User Datagram Protocol)

  • 역할: TCP와 마찬가지로 데이터 전송 시 신뢰성을 보장하기 위해 약속해놓은 규범
  • 특징
    • 3-way handshake 기능이 없다.
    • 데이터 전달 보증이 없다.
    • 순서 보장이 되지 않는다.
    • PORT(패킷 구분을 위함)와 체크섬(메시지 검증)만 추가되어 있다.
    • 최근 각광받고 있다.
  • 장점
    • 3-way handshake를 하지 않아 전송 속도가 빠르다.
    • 원하는대로 최적화가 가능

 

PORT

  • 역할: 같은 IP 내에서 프로세스를 구분할 때 사용한다.
  • 특징
    • 0 ~ 65535가 할당 가능한 포트 번호이다.
    • 0 ~ 1023은 잘 알려진 포트 번호로 사용하지 않는 것이 좋다.
      • FTP-20,21 | TELNET-23 | HTTP-80 | HTTPS-443

 

DNS (Domain Name System)

  • 역할: IP는 변경될 수 있고, 기억하기 어렵기 때문에 도메인 명을 붙여 IP 대신 사용한다.

 

Summary

- 복잡한 인터넷망에서 메시지를 보내기 위해선 인터넷 프로토콜인 IP가 있어야 한다.
- 하지만 메시지가 잘 도착했는지 확인할 때 IP만으로는 한계가 있어 TCP를 사용해 패킷 소실 문제나 패킷 순서 문제를 일으키지 않도록 보장받는다.
- UDP는 거의 IP와 같은 통신 규범인데 Port 정보를 추가해 같은 IP 내에서 프로세스를 구분할 수 있게 도와준다.
- IP는 변하기 쉽고 외우기 어려워 DNS를 통해 사용하기 용이하도록 했다.

 


2. URI와 웹 브라우저 요청 흐름

URI (Uniform Resource Identifier)

URI는 URL(Locator)과 URN(Name)을 포괄하는 개념이다.

 

  • URL 전체 문법
    • scheme://[userinfo@]host[:port][/path][?query][#fragment]
      • scheme: 주로 프로토콜을 작성하고 우리는 http나 https를 사용한다.
      • [userinfo@]: URL에 사용자 정보를 포함해서 인증할 때 사용하는데 거의 사용하지 않는다;
      • host: 도메인명이나 IP주소를 작성한다. ex) www.google.com  
      • [:port]: 접속 포트를 작성하는 부분이나 생략하는 것이 일반적이다.
      • [/path]: 리소스의 경로를 작성하는 부분이다. ex) /members, /search, /home/file1.jpg
      • [?query]: key=value 형태로 ?로 시작하고 &으로 key=value를 추가할 수 있다. 쿼리 파라미터, 쿼리 스트링으로 불린다. ex) ?key1=value1&key2=value2
      • [#fragment]: html 내부 북마크 등에 사용하는 것으로 서버에 전송하는 정보는 아니다.

 

 

웹 브라우저 요청 흐름

1. 웹 브라우저가 인터넷에 https://www.google.com/search?q=hello&hl=ko 요청한다.
2. DNS 서버 조회한다.
2. 요청을 하려는 웹 브라우처는 HTTP 요청 메시지를 생성한다.
GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com​

3. HTTP 요청 메시지는 인터넷 프로토콜 4 계층을 거쳐 해당 메시지에 출발지IP, 목적지IP, 그 외의 것들이 붙어 패킷으로 생성된다.
출발지 IP, PORT
목적지 IP, PORT
전송 데이터(이게 HTTP 요청 메시지)
그 외​

4. 웹 브라우저는 해당 패킷을 서버에 전송한다.
5. 서버는 HTTP 응답 메시지를 웹 브라우저에 전달한다.
HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Length: 3423

<html>
<body>...</body>
</html>​

6. 웹 브라우저에는 HTML이 렌더링 된다. 성공!

 


 

3. HTTP

모든 것이 HTTP

  • HTTP: HyperText Transfer Protocol
  • 초기에는 HTML을 전송하는 프로토콜이었는데 현재는 모든 형태의 데이터를 전송할 때 사용함
  • HTTP 역사
    • HTTP/1.1 1997년: 가장 많이 사용하고 우리에게 가장 중요한 버전
    • HTTP/3 진행 중: TCP 대신 UDP 사용, 성능 개선 위주
  • 기반 프로토콜
    • TCP: HTTP/1.1, HTTP/2
    • UDP: HTTP/3
  • HTTP 특징
    • 클라이언트 서버 구조로 이뤄져 있음
    • 무상태 프로토콜(Stateless), 비연결성
    • HTTP 메시지
    • 단순함, 확장 가능

 

클라이언트 서버 구조

  • 클라이언트와 서버를 분리하는 것이 중요함
  • 비즈니스 로직과 데이터는 서버에, 클라이언트는 UI 사용성에 집중하면 양쪽이 독립적으로 진화할 수 있어 효율적임
  • Request Response 구조
    • 클라이언트: 서버에 요청을 보내고, 응답을 기다림
    • 서버: 요청에 대한 결과를 만들어서 클라이언트에 응답을 보냄

무상태 프로토콜 (Stateless)

Stateful, Stateless 차이
- Stateful: 서버는 클라이언트의 이전 상태를 기억하고 있어 항상 같은 서버로 유지되어야 함 (상태 유지)
- Stateless: 서버는 클라이언트의 이전 상태를 기억 못 하지만, 클라이언트는 서버에 필요한 정보를 모두 제공해 줌 (무상태)
👉🏻 무상태는 응답 서버를 쉽게 바꿀 수 있고, 이는 즉 무한한 서버 증설이 가능(스케일 아웃에 유리)하다는 뜻이다.

 

  • Stateless
    • 실무에서의 한계
      • 모든 것을 무상태로 설계할 수 있지만, 그렇지 못한 경우도 있음
      • 로그인이 필요 없는 단순한 서비스 소개 화면은 무상태 프로토콜 사용이 가능함
      • 로그인이 필요한 서비스의 경우, 로그인했다는 상태를 서버에 유지해야 하고, 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해 상태를 유지함 -> 상태 유지는 최소한으로 사용해야 하고, 꼭 써야 하는 경우라면 어쩔 수 없이 사용해야 함
      • Stateful보다 Stateless가 한 번에 많은 데이터를 전송함

비연결성(connectionless)

- 연결을 유지하는 모델
   - 연결을 유지하는 동안 리소스가 낭비되는 문제가 발생
- 연결을 유지하지 않는 모델
   - TCP/IP로 연결을 하고 요청과 응답이 끝나면 연결을 끊어 서버 유지 자원을 최소한으로 줄일 수 있음

 

  • 특징
    • HTTP는 기본이 연결을 유지하지 않는 모델
    • 일반적으로 초 단위 이하의 빠른 속도로 응답
    • 1시간 동안 수천 명이 서비스를 사용해도 수천 명을 동시에 연결하고 있지 않기 때문에 서버가 실제로 처리하는 요청은 수십 개 이하로 매우 적음
    • 서버 자원을 효율적으로 유지 가능함 
  • 한계와 극복
    • 3 way handshake를 통해 TCP/IP 연결을 새로 맺어야 해 연결할 때 시간이 추가됨
    • 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등 수많은 자원이 함께 다운로드됨
    • 지금은 HTTP 지속 연결(persistent connection)로 문제를 해결함
  • Stateless를 기억하자! 티켓팅과 같이 같은 시간에 동시에 몰려오는 대용량 트래픽을 최대한 stateless하게 설계하는 것이 중요함!

HTTP 메시지 구조

  • 1️⃣ start-line (시작 라인) = request-line / status-line
    • request-line
      • request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)
      • GET /search?q=hello&hl=ko HTTP/1.1  
        • method
          • 종류: GET, POST, PUT, DELETE
          • 서버가 수행해야 할 동작 지정
        • request-target (요청 대상)
          • absolute-path[?query] (절대경로[?쿼리])
          •  절대경로 / 로 시작하는 경로
        • HTTP-version
      • status-line
        • status-line = HTTP-version SP status-code SP reason-phrase CRLF
        • HTTP/1.1 200 OK 
          • HTTP-version
          • status-code
            • 200: 성공
            • 400: 클라이언트 요청 오류
            • 500: 서버 내부 오류
          • reason-phrase: 사람이 이해할 수 있는 짧은 상태 코드 설명 글
  • 2️⃣ header (헤더)
    • header-field = field-name: OWS field-value OWS(띄어쓰기 허용)
    • ex)
      • Host: www.google.com 
  • 3️⃣ empty line (공백 라인, CRLF)
  • 4️⃣ message body
    • 실제 전송할 데이터

 

HTTP 정리

1. HTTP 메시지에 모든 것을 넣어 전송한다.
2. HTTP 역사 HTTP/1.1을 기준으로 학습한다.
3. 클라이언트 서버 구조이다.
4. 무상태 프로토콜이다.
5. HTTP 메시지 구조
6. HTTP는 단순하고, 확장 가능하다.
7. 지금은 HTTP의 시대이다.

 


 

다음 글은 HTTP에 대해 더 자세히 정리해서 가져오겠습니다!

마지막은 웃긴 짤 투척할게요

 

 

 


해당 포스팅은 김영한님의 인프런 강의 "모든 개발자를 위한 HTTP 웹 기본 지식"을 바탕으로 작성했습니다.