인터넷 프로토콜과 HTTP 개요

---

---

---

IP(인터넷 프로토콜)

• 지정한 IP 주소에 데이터 전달
• 패킷(Packet)이라는 통신 단위로 데이터 전달
• IP 패킷 정보: 출발지 IP, 목적지 IP, 기타

IP 프로토콜의 한계

• 비연결성: 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
• 비신뢰성: 중간에 패킷이 사라지거나, 패킷이 순서대로 온다는 보장이 없음
• 프로그램 구분: 같은 IP를 사용하는 서버에서 통신하는 애플리케이션을 구별할 수 없음

---

TCP(전송 제어 프로토콜 - Transmission Control Protocol)

• TCP 패킷 정보: 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보 등
  • TCP/IP 패킷이 합쳐지면서 출발지/목적지 IP와 PORT 정보 확인 가능

TCP 특징

• 연결지향: TCP 3 way handshake (가상 연결)
  1. 클라이언트가 서버로 SYN (접속 요청) 전달
  2. 서버가 클라이언트에게 SYN + ACK(요청 수락)를 통해 접속 요청 및 요청 수락 메시지 전달
  3. 클라이언트가 서버에게 ACK 전달
  4. 데이터 전송 (요즘에는 3번 과정에서 데이터 함께 전송 가능)
• 데이터 전달 보증
• 순서 보장
• 신뢰할 수 있는 프로토콜

---

UDP (사용자 데이터그램 프로토콜 - User Datagram Protocol)

• PORT, 체크섬 기능이 추가로 있다는 것 외에 IP와 다를 바 없음
• 연결지향  X - TCP 3 way handshake X
• 데이터 전달 보증 X
• 순서 보장 X
• 데이터 전달 및 순서가 보장되지 않는 대신 단순하고 빠름

---

PORT 

• 같은 IP 내에서 프로세스를 구분하기 위한 항구 역할

• 0 ~ 65535 할당 가능
  • 0 ~ 1023: 잘 알려진 포트로 사용하지 않는 것이 좋음
  • FTP: 20, 21
  • TELNET: 23
  • HTTP: 80
  • HTTPS: 443

---

DNS (도메인 네임 시스템 - Domain Name System)

• 기억하기 어렵고, 변경될 수도 있는 IP를 보완하기 위한 네임 시스템
• 전화번호부 역할로 도메인 명을 IP 주소로 변환 

 

 

---

URI (Uniform Resource Identifier)

• Uniform: 리소스 식별하는 통일된 방식
• Resource: 자원, URI로 식별할 수 있는 모든 것 (제한 없음)
• Identifier: 다른 항목과 구분하는데 필요한 정보
• URI는 locator, name 또는 둘 다 추가로 분류될 수 있다.

URL (Uniform Resource Locator)

• 리소스가 있는 위치를 지정

URN (Uniform Resource Name)

• 리소스에 이름을 부여
• URN 이름만으로 실제 리소스를 찾을 수 있는 방법이 보편화되지 않아, URL을 주로 사용

 

 

• 우리가 일반적으로 웹 브라우저에서 보는 http ~ 주소가 URL
• 이름을 부여해서 주소를 매핑하는 것이 URN 

URL (URI) 전체 문법

scheme://[userInfo@]host[:port][/path][?query][#fragment]

https://www.google.com:443/search?q=hello&hl=ko

 

• 프로토콜: https
  
  • scheme은 주로 프로토콜 사용(http, https, ftp 등)
• 호스트명: www.google.com
  • 도메인명 또는 IP 주소 직접 사용 가
• 포트 번호: 443
  • 포트는 생략 가능
  • 생략 시 http는 80, https는 443
• 패스: /search
  • 리소스 경로, 계층적 구조
  • /home/file.jpg, /members, /members/100,...
• 쿼리 파라미터: q=hello&hl=ko
  • key=value 형태
  • ?로 시작, &로 추가 가능: ?key1=value1&key2=value2
  • query parameter, query string 등으로 불림, 웹 서버에 제공하는 파라미터로 문자 형
• 참고로, userInfo@ 는 URL에 사용자정보를 포함해서 인증하는 정보로 거의 사용하지 않는다.
• fragment: html 내부 북마크 등에 사용하는 정보로 서버에 전송하는 정보는 아님
  • https://docs.spring.io/spring-boot/docs/current/reference/html/getting-started.html#getting-started-introducing-spring-boot

---

웹 브라우저 요청 흐름

---

---

 

 

---

 

HTTP 메시지 전송 (클라이언트 → 서버)

---

 

HTTP 응답 메시지 전송 ( 서버 → 클라이언트)

HTTP

HyperTest Transfer Protocol

• 거의 모든 형태의 데이터를 HTTP 메시지에 담아 전송 가능
  • HTML, TEST, IMAGE, 음성, 영상, 파일, JSON, XML (API) emd
• 서버 간에 데이터를 주고받을 때도 대부분 HTTP 사용
• HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전
• HTTP/2 2015년: 성능 개선
• HTTP/3 진행 중: TCP 대신에 UDP 사용, 성능 개선

 

기반 프로토콜

• TCP: HTTP/1.1, HTTP/2
• UDP: HTTP/3

 

HTTP 특징

• 클라이언트 서버 구조
• 무상태 프로토콜(stateless), 비연결성
• HTTP 메시지를 통해 동작
• 단순함, 확장 가능

클라이언트 서버 구조

• Request(클라이언트 → 서버) Response(서버 → 클라이언트) 구조
• 클라이언트는 로직 대신 UI/UX에 집중하고, 서버는 비즈니스 로직에 집중할 수 있다. 즉, 클라이언트 서버 구조는 양쪽이 독립적으로 진화 가능하다는 장점 존재한다.

무상태 프로토콜 (Stateless)

• 서버가 클라이언트의 상태를 보존 X
  • 장점: 서버 확장성 높음 (scale - out)
  • 단점: 클라이언트가 추가로 데이터 전송 필요
• 무상태는 응답 서버를 쉽게 바꿀 수 있다 →  무한한 서버 증설 가능
• 한계 존재: 무상태로 설계할 수 있는 경우가 있고 없는 경우가 존재
  • 무상태: 로그인이 필요 없는 단순한 서비스 소개 화면 등
  • 상태 유지: 로그인
    • 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지: 일반적으로 브라우저 쿠키와 서버 세션 등 사용해 상태 유지
    • 상태 유지는 최소한만 사용

비연결성

• 요청을 주고받을 때만 연결하고 그 후는 끊음으로써 최소한의 자원 사용
• HTTP는 기본이 연결을 유지하지 않는 모델
• 일반적으로 초 단위 이하의 빠른 속도로 응답
• 1시간 동안 수천 명이 서비스를 동시에 사용해도, 실제 서버에서 동시에 처리하는 요청은 수십 개 이하로 매우 작다.
  • 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.
• 서버 자원 효율적 사용 가능
• 한계 존재
  • TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가
  • 웹 브라우저로 사이트를 요청하면 HTML, 자바스크립트, CSS 등 수많은 자원이 함께 다운로드되는데, 자원을 받을 때마다 연결하고 끊고를 반복하는 것은 비효율적
  • 지금은 HTTP 지속 연결 (Persistent Connections)로 문제 해결
    • HTTP/2, HTTP/3에서 더 많은 최적화

---

HTTP 메시지 구조

---

---

 

시작 라인

• start-line = request-line (요청 시) / status-line (응답 시)

1. 요청 메시지
   1. •  

• request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)
• method: GET (리소스 조회)
• request-target(요청 대상): /search?q=hello&hl=ko - 절대경로[?쿼리]
  • 절대경로 = "/"로 시작하는 경로
  • 참고로, *, http://...?x=y와 같이 다른 유형의 경로 지정 방법도 존
• HTTP version: HTTP/1.1

   2. 응답 메시지

• status-line = HTTP-version SP status-code SP reason-phrase CRLF
• HTTP version: HTTP/1.1
• HTTP 상태 코드: 요청 성공/실패 나타냄
  • 200: 성공
  • 400: 클라이언트 요청 오류
  • 500: 서버 내부 오류
• 이유 문구: 사람이 이해할 수 있는 짧은 상태 코드 설명 

---

HTTP 헤더

• header-filed = field-name ":" OWS field-value OWS (OWS: 띄어쓰기 허용)
• field-name은 대소문자 구문 없음
• HTTP 전송에 필요한 모든 부가정보
  • 메시지 바디 내용, 메시지 바디 크기, 압축, 인증, 요청 클라이언트 (브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보 등
• 필요시 임의의 헤더 추가 가능

---

HTTP 메시지 바디

• 실제 전송할 데이터
• HTML 문서, 이미지, 영상, JSON 등 byte로 표현할 수 있는 모든 데이터 전송 가능 

---

[출처]

김영한, "모든 개발자를 위한 HTTP 웹 기본 지식", 인프런