A ship in harbor is safe, but that is not what ships are built for.

STUDY/Network

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

플리피나리 2024. 12. 5. 16:38
반응형

1. URI

= Uniform Resource Identifier

URI는 로케이터, 이름 또는 둘다 추가로 분류될 수 있음

URI(리소스 식별) = URL(리소스 위치) + URN(리소스 이름)

→ 위치는 변할 수 있지만, 이름은 변하지 않음

  BUT, URN만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않음

 

sheme://{userinfo@}host[:post][/path][?query][#fragment]

프로토콜(HTTP, HTTPS, FTP)://HostName:Port/Path?QueryParameter

→ 일반적으로 HTTP는 80포트, HTTPS(HTTP Secure)는 443포트를 이용하기에 포트번호 생략

→ userinfo@는 URL에 사용자 정보를 포함해서 인증(거의 사용 X)

→ path는 리소스 경로로 주로 계층적 구조

→ query는 key=value형태로 ?로 시작해 &로 추가 가능(query에 넘어가는 정보는 string으로 넘어감)

→ fragment는 HTML 내부 북마크에 사용(서버로 전송되는 정보 X)

 

 

2. 웹 브라우저 요청 흐름

  1. 웹 브라우저는 URL에서 얻은 도메인 이름으로 DNS를 조회해 IP 정보를 얻고, 프로토콜 방법 등에서 Port번호를 얻음
  2. HTTP 요청 메시지 생성
  3. 소켓 라이브러리를 통해 OS에 전달
  4. OS 계층에서 IP와 Port 정보를 추가해 TCP/IP 패킷 생성 및 추가
  5. 인터넷으로 서버에 전달
  6. 서버는 TCP/IP 패킷을 벗긴 후 HTTP 요청 메시지를 읽고 HTTP 응답 메시지를 생성
  7. 다시 응답 메시지에 TCP/IP 패킷 생성 및 추가 후 웹 브라우저에 전송

 

 

3. 모든 것이 HTTP

HTTP = HyperText Transfer Protocol

HTTP 메시지에 모든 것을 전송 → HTML, Text, Image, 음성, 영상, 파일, JSON, XML(거의 모든 형태의 데이터), 서버 간 데이터 통신

HTTP/1.1, HTTP/2 → TCP 기반

HTTP/3 → UDP 기반

HTTP의 특징

  • 클라이언트 - 서버 구조
  • 무상태 프로토콜(Stateless), 비연결성
  • HTTP 메시지를 통해 통신
  • 단순, 확장 쉬움

 

 

4. 클라이언트 서버 구조

클라이언트 → 서버 : Request(요청) ⇒ 클라이언트는 서버에 요청을 보내고, 응답을 대기

서버 → 클라이언트 : Response(응답) ⇒ 서버가 요청에 대한 결과를 만들어 응답

**클라이언트와 서버가 독립적으로 발전 가능!!!

 

 

5. Stateful, Stateless

무상태 프로토콜 = Stateless : 서버가 클라이언트의 상태를 보존 X ↔ Stateful(항상 같은 서버가 유지)

  • 중간에 연결을 유지하지 않아도 매 요청을 정확히 이해 가능 → ex) 노트북, 2개, 신용카드 결정
  • 아무 서버나 호출 가능
  • Pros) 서버 확장성 높음 → 스케일 아웃(수평 확장)
  • Cons) 클라이언트가 추가 데이터 전송
  • 한계
    • 상태를 유지해야 하는 경우 → 로그인(브라우저 쿠기, 서버 세션)
    • 따라서, 상태 유지는 최소한만 사용

 

 

6. 비연결성

연결을 유지하는 모델 → 서버는 연결을 계속 유지, 서버 자원 소모

연결을 유지하지 않는 모델 → 서버는 연결 유지 X, 최소한의 자원 유지

HTTP는 기본적으로 비연결성 모델 → 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음

BUT, TCP/IP 연결을 매번 새로 연결 → 3 way handshake 시간 추가

웹 브라우저로 사이트 요청 시 수많은 자원이 함께 다운로드 ⇒ HTTP Persistent Connections으로 해결

수많은 동시 요청 → 최대한 Stateless 방식으로 설계

 

 

7. HTTP 메시지

HTTP 메시지 = start-line + header + empty-line(CRLF) + message-body

  1. Start-Line
    • Request-Line OR Status-Line
    • Request-Line = HTTP-method + SP(공백) + Request-Target + HTTP-Version + CRLF
    • Request-Target은 절대경로[?쿼리] 형 → /로 시작
    • Status-Line = HTTP-Version + SP + Status-Code + SP + Reason-Phrase + CRLF
  2. HTTP Header
    • field-name: field-value 형태 → 대소문자 구분 X
    • HTTP 전송에 필요한 모든 부가정보 → 메시지 바디 내용, 메시지 바디 크기, 압축, 인증, 브라우저 정보, 서버 애플리케이션 정보, 캐시 관리 정보 등
    • 필요 시 임의 헤더 추가 가능
  3. HTTP Message Body
    • 실제 전송할 데이터 → byte로 표현 가능한 모든 데이터 전송 가능
반응형

'STUDY > Network' 카테고리의 다른 글

Ch05. HTTP헤더1 - 일반 헤더  (1) 2024.12.15
Ch04. HTTP 상태코드  (1) 2024.12.14
Ch03. HTTP 메서드  (0) 2024.12.06
Ch01. 인터넷 네트워크  (0) 2024.12.05