모든 개발자를 위한 HTTP 웹 기본 지식

인터넷 통신

IP(Internet Protocol)

• 복잡한 인터넷 망에서 상대 컴퓨터를 어떻게 찾아가는가

IP 주소 부여

역할

• 지정한 IP 주소(IP Address)에 데이터 전달

• 패킷(Packet)이라는 통신 단위로 데이터 전달

IP 패킷 정보

클라이언트 패킷 전달

서버 패킷 전달

한계

• 비연결성
• 패킷을 받을 대상이 없거나, 서비스 불능 상태여도 패킷을 전송
• 편지처럼

• 비신뢰성
• 중간에 패킷이 사라지면?
• 패킷이 순서대로 오지 않으면?

• 프로그램 구분
• 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이면?
• Port(포트)

IP 스택 4계층

프로토콜 계층

IP 패킷 VS TCP/IP 패킷

TCP(Transmission Control Protocol)

전송 제어 프로토콜

• IP의 비신뢰성 문제를 해결하기 위해 탄생

• 연결지향 - TCP 3 way handshake(가상 연결)

• 데이터 전달 보장

• 순서 보장

• 신뢰할 수 있는 프로토콜

• 현재는 대부분 TCP 사용

TCP 3 way handshake

• SYN: 접속 요청

• ACK: 요청 수락

• 참고
• ACK와 함께 데이터 전송 가능

데이터 전달 보장

순서 보장

UDP(User Datagram Protocol)

사용자 데이터그램 프로토콜

• 하얀 도화지에 비유됨(기능이 거의 없음)

• 연결지향 X - TCP 3 way handshake X
• 데이터전달보증X
• 순서 보장 X
• 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름

• 정리
• IP와 거의 같다. + PORT + CheckSum 정도만 추가됨
• 애플리케이션에서 추가 작업 필요

Port

하나의 IP Address로 둘 이상 연결해야 할 때

• 같은 IP 내에서 프로세스를 구분한다.

TCP/IP 패킷 정보

특징

• 0 ~ 65535 할당 가능

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

DNS(Domain Name System)

• 전화번호부와 같음

• 도메인 명을 IP 주소로 변환

URI(Uniform Resource Identifier)

"URI는 로케이터(Locator), 이름(Name) 또는 둘 다 추가로 분류될 수 있다."

• Uniform: 자원을 식별하는 통일된 방식

• Resource: 자원, URI로 식별할 수 있는 모든 것(제한 없음)

• Identifier: 다른 항목과 구분하는데 필요한 정보

URL VS URN

• URL - Locator: 리소스가 있는 위치를 지정

• URN - Name: 리소스에 이름을 부여

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

• urn:isbn:8960777331 (어떤 책의 isbn URN)

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

• 앞으로 URI은 URL과 같은 의미로 이야기하겠음

URL

문법

• 프로토콜(https)
• 포트 번호(443)
• http는 80 포트, https는 443 포트를 주로 사용, 포트는 생략 가능
• https는 http에 보안 추가 (HTTP Secure)

• userinfo
• URL에 사용자정보를 포함해서 인증
• 거의 사용하지 않음

• 호스트명(www.google.com)
• 도메인명 또는 IP 주소를 직접 사용가능

• Port
• 접속 포트
• 일반적으로 생략, 생략시 http는 80, https는 443

• Path(/search)
• 리소스 경로(path)
• 계층적 구조

• Query Parameter(q=hello&hl=ko)
• key=value 형태
• ?로 시작, &로 추가 가능 ?keyA=valueA&keyB=valueB
• query parameter, query string 등으로 불림
• 웹서버에 제공하는 파라미터, 문자 형태

• fragment
• https://docs.spring.io/spring-boot/docs/current/reference/html/getting-started.html#getting-started-introducing-spring-boot
• html 내부 북마크 등에 사용
• 서버에 전송하는 정보 아님

웹 브라우저의 요청 흐름

• HTTP 요청 메시지 생성



• HTTP 요청 메시지

• HTTP 메시지 전송

• 패킷 생성

• 요청 패킷 전달

• 요청 패킷 도착

• HTTP 응답 메시지 생성

• 응답 패킷 전달

• 응답 패킷 도착

• 웹 브라우저 HTML 렌더링

HTTP(HyperText Transfer Protocol)

HTTP 메시지에 모든 것을 전송

• HTML, TEXT

• IMAGE, 음성, 영상, 파일

• API
• JSON, XML

• 거의 모든 형태의 데이터 전송 가능

• 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용

• 지금은 HTTP 시대!

역사

• HTTP/0.9 1991년: GET 메서드만 지원, HTTP 헤더X

• HTTP/1.0 1996년: 메서드, 헤더 추가

• HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전
• RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014)

• HTTP/2 2015년: 성능 개선

• HTTP/3 진행중: TCP 대신에 UDP 사용, 성능 개선

기반 프로토콜

• TCP: HTTP/1.1, HTTP/2

• UDP: HTTP/3

• 현재 HTTP/1.1 주로 사용
• HTTP/2, HTTP/3 도 점점 증가

특징

• 클라이언트 서버 구조

• 무상태 프로토콜(Stateless), 비연결성

• HTTP 메시지

• 단순함, 확장 가능

클라이언트-서버 구조

• Request-Response 구조

• 클라이언트는 서버에 요청을 보내고, 응답을 대기

• 서버가 요청에 대한 결과를 만들어서 응답

무상태 프로토콜(Stateless)

• 서버가 클라이언트의 상태를 보존X

• 장점
• 서버 확장성 높음(스케일 아웃)
• 수평 확장에 유리
• 여러 개의 서버 중 아무 서버나 호출해도 된다.

• 단점
• 클라이언트가 추가 데이터 전송
• 모든것을 무상태로 설계할 수 있는 경우도 있고, 없는 경우도 있다.
• 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지
• 일반적으로 브라우저 쿠키와 서버 세션 등을 사용해서 상태 유지
• 상태 유지는 최소한만 사용

비연결성(Connectionless)

서버는 연결 유지X, 최소한의 자원 유지

• 초 단위 이하의 빠른 속도로 응답

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

• 서버 자원을 매우 효율적으로 사용할 수 있음

• TCP/IP 연결을 새로 맺어야 함 - 3 way handshake 시간 추가

• 웹 브라우저로 사이트를 요청하면 HTML 뿐만 아니라 자바스크립트, css, 추가 이미지 등 수 많은 자원이 함께 다운로드됨

• 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결

• HTTP/2, HTTP/3에서 더 많은 최적화

출처