[김영한, inflearn] 모든 개발자를 위한 HTTP 웹 기본 지식(미완)

: https://inf.run/pkYP

 

---

목차

---

1. 인터넷 네트워크

: 인터넷 네트워크 망의 기본에 의해 모든것이 돌아간다.

1.1 인터넷 통신 : 어떻게 저 복잡한 망을 거쳐서 소통을 하는 것인가?

1.2 IP(인터넷 프로토콜)

A.  정의

- 지정한 IP 주소(IP Address)에 데이터를 전달하는 "규칙"

- 통신단위 "패킷(Packet)"으로 데이터 전달

 

B. IP패킷 정보(택배 운송장 적는 느낌이다)

- 출발지 IP 주소 + 목적지 IP 주소+ 메세지 + 기타로 구성

ex) hello world! 메세지를 한국에서 미국으로 보내기

- 패킷을 작성해서 인터넷 망에 던지면, 서버 노드들이 규약에 따라 전달해 준다.(모든 노드는 IP프로토콜 규약을 따르고 있음)

 

C. IP 프로토콜의 한계 => TCP, UDP가 해결해 준다!

C.1 비연결성 : 수신쪽 PC가 꺼져있어도 보냄

- 패킷 수신 대상이 없거나, 서비스 불능이어도 패킷 전송

 

C.2 비신뢰성 : 패킷 내용 보장이 안됨

- 중간에 패킷 유실

- 여러개 보낼 때, 패킷이 순서대로 안오는 경우(1500Byte 넘으면 보통 메세지 끊어서 보냄)

 

C.3 프로그램 구분 : 같은 IP의 애플리케이션이 둘 이상인 경우 구분 불가.

- 한 PC에서 게임도하고, 음악도 듣고..

 

1.3 TCP, UDP

: IP프로토콜 문제 해결해 줌. IP위에 TCP를 올려서 보완한다.

채팅프로그램으로 Hello, world! 메세지를 미국에 보내는 케이스(capsulate)

A. 인터넷 프로토콜 스택의 4계층

1. 애플리케이션 계층(HTTP,FTP)

: Socket 라이브러리 사용해 OS 계층에 메세지 전달

 

2. 전송계층(TCP,UDP)

: TCP정보 생성, 메세지 데이터 포함

 

3. 인터넷 계층(IP)

: IP 패킷 생성, TCP 데이터 포함

 

4. 네트워크 인터페이스 계층(LAN카드 - 네트워크 드라이버 등등..)

IP 패킷 + Ethernet frame 생성(MAC 주소 등등..)

 

B. Packet이란 : Package(패키지) + Bucket(덩어리) 합성어

C. TCP(Transmission Control Protocol, 전송제어 프로토콜) 특징 

: 신뢰할 수 있는 프로토콜, 대부분 TCP 사용

 

1. 연결 우선 : 양족 회선 연결이 확인된 후 메세지를 보낸다.

- TCP 3 way handshake(가상연결=중간연결노드를 모른다는 의미, 전용선이 아님), 

--> 옛날에는 실제 랜선 포트를 뽑아서 교환해 줬음(물리연결)

- SYN -> SYN+ACK -> ACK(최적화 되서, 요즘엔 마지막 ACK에 데이터 같이 날림) : 싱싱엨엨

 

2.데이터 전달 보증 : 수신 후 ACK를 날려 줌

- 제대로 수신 됐는지 안됐는지 알 수 있다.

 

3.순서 보장

 1,2,3 -> 1,3,2 로 도착 -> 패킷 2부터 다시 보내

 

D. 원리 : 출발Port, 목적 Port, 전송제어, 순서, 검증정보 등이 포함되어 있어서 

E. UDP  : TCP같은 기능 하나도 없음 but 최적화를 내 맘대로

- 하얀 도화지 = handshake X, 데이터 전달보증 X, 순서보장 X

- port(여러 애플리케이션) + checksum(데이터검증) 정도 추가 됨.

- 단순하고 빠르다(핸드쉐이크 안해서).

- 애플리케이션에서 추가 작업 필요함

- 최근에 UDP가 뜨고 있음 : Http3에서, 핸드쉐이크 까지 줄여보자의 의도로 UDP 사용

 

1.4 PORT : 배가 도착하는 항구

: 패킷이 어디에서 필요한 패킷인지 구분하는 용도. IP만으로 구분하기 힘들다.

A. IP는 서버 찾기, Port는 application 찾기

- 같은 IP내에서 프로세스를 구분하는 것

- IP가 아파트라면, port는 몇동 몇호

B. 0~65535 할당 가능

- 0~ 1023 : 잘 알려진 포트로, 사용하지 않는 것이 좋음

- FTP - 20,21

- TELNET - 23

- HTTP - 80

- HTTPS - 443

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

A. 해결할 문제

1. ip는 기억하기 어렵다

2. ip는 변경될 수 있다.

B. 전화번호부 같은 서버, 도메인 명을 IP주소로 변경

C. DNS서버에 domain 구매 후 등록 : 도메인 요청 시 dns서버에서 현재 ip반환

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

2.1 URI(Uniform Resource Identifier)

A. URI, URL, URN 

A.1 URI는 Locator(URL, 리소스의 위치), name(URN, 리소스의 이름) 또는 둘다 추가로 분류 될 수 있다.

> https://www.ietf.org/rfc/rfc3986.txt - 1.1.3. URI,URL, and URN

 

B. 단어 뜻

B.1 URI  : Uniform(리소스 식별하는 통일된 방식) Resource(자원, URI로 식별할 수 있는 모든 것) Identifier(구분에 필요한 정보)

B.2 URN : 리소스에 이름을 부여

> isbn 등에 쓴다.

> URN만으로 실제 리소스 찾는 방법이 보편화 되지 않음

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

B.3 URL : 리소스가 있는 위치를 지정. URI = URL 거의 같은 의미로 쓴다.

 

C. URL 문법 : 예제 https://www.google.com/search?q=hello&hl=ko

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

> 프로토콜=https, 호스트명=www.google.com, 포트번호=443, path=/search, 쿼리 파라미터=q=hello&hl=ko

 

C.1 scheme

> 주로 프로토콜 사용. 어떤 방식으로 자원에 접근할 것인가 하는 약속 규칙(http(80),https(443),ftp등)

> 포트는 생략 가능. 

C.2 userinfo

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

C.3 host

> 호스트명. 도메인명 or IP주소 직접 사용 가능

C.4 port

> 접속포트. 생략가능하고 생략시 http=80, https=443

C.5 path

> 리소스가 있는 경로. 계층적 구조로 되어 있음

> ex) /home/file1.jpg, /members, /members/100, /items/iphone12

C.6 query

> key=value 형태로 데이터 들어감. ?로  시작, &로 추가가능, => ?keyA=valueA&keyB=valueB

> query parameter(서버에 제공하는 파라미터), query string(String으로만 전달) 등으로 불림

C.7 fragment

> 잘 사용하지 않음, html 내부 북마크에 사용하며, 서버에 전송되는 정보는 아님

> ex)

https://docs.spring.io/spring-boot/docs/current/reference/html/gettingstarted.html#getting-started-introducing-spring-boot

 

2.2 웹 브라우저 요청 흐름

 > 예제 : https://www.google.com/search?q=hello&hl=ko

A. ip와 port 정보 찾기 : DNS 조회, 프로토콜 확인

B. http요청 메세지 생성 : 방식 + path~query + http 버전정보 + host 정보

GET /search?q=hello&hl=ko HTTP/1.1
HOST: www.google.com

C.  패킷 생성 후 전달

D. 패킷 수신 후 해석 > 응답 작성 및 전송

> TCP/IP 패킷을 까서 버린다 > 메세지 read후 해석한다. >  응답메세지 작성(content type 중요) > 패킷 송신 > 브라우저가 수신 후 랜더링

3. HTTP 기본

3.1 모든 것이 HTTP(HyperText Transfer Protocol)

: html(문서간의 링크를 통해서 연결할 수 있는)을 전송하는 프로토콜

> 현재는 html뿐만 아니라 모든 데이터를 http에 담아서 전송. 서버간에도!

> HTML, TEXT, IMAGE, 음성, 영상, 파일, JSON, XML (API), 거의 모든 형태의 데이터 전송 가능, 서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용

> 특수한 게임 제외, TCP 그대로 쓰는 경우 없음.

A. http역사 : http1에서 부터 현재 스팩 형태 > http2,3는 성능개선에 초점

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

> HTTP/1.0 1996년: 메서드, 헤더 추가
> HTTP/1.1 1997년: 가장 많이 사용, 우리에게 가장 중요한 버전. RFC7230 알아야 함
    • RFC2068 (1997) -> RFC2616 (1999) -> RFC7230~7235 (2014) 

> HTTP/2 2015년: 성능 개선
> HTTP/3 진행중: TCP 대신에 UDP 사용, 성능 개선

 

B. 기반 프로토콜

B.1 HTTP/1.1, HTTP/2 : TCP 기반, TCP 위에서 동작 

B.2 HTTP/3 : UDP 기반 개발

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

B.3 예시

> 크롬 개발자도구 > 우클릭 > 프로토콜 컬럼 추가

> http/1.1 = http1.1 , h2 = http2, h3 = http3

C.특징

> 클라이언트 서버 구조로 동작

> 무상태 프로토콜(스테이스리스) 지향, 비연결성
> HTTP 메시지를 통해서 통신
> 단순함, 확장가능

 

3.2 클라이언트 서버 구조

3.3 Stateful, Stateless

3.4 비 연결성(connectionless)

3.5 HTTP 메시지

4. HTTP 메서드

HTTP API를 만들어보자
HTTP 메서드 - GET, POST
HTTP 메서드 - PUT, PATCH, DELETE
HTTP 메서드의 속성

5. HTTP 메서드 활용

클라이언트에서 서버로 데이터 전송
HTTP API 설계 예시

6. HTTP 상태코드

HTTP 상태코드 소개
2xx - 성공
3xx - 리다이렉션1
3xx - 리다이렉션2
4xx - 클라이언트 오류, 5xx - 서버 오류

7. HTTP 헤더 - 일반 헤더

HTTP 헤더 개요
표현
콘텐츠 협상
전송 방식
일반 정보
특별한 정보
인증
쿠키

8. HTTP 헤더2 - 캐시와 조건부 요청
캐시 기본 동작
검증 헤더와 조건부 요청1
검증 헤더와 조건부 요청2
캐시와 조건부 요청 헤더
프록시 캐시
캐시 무효화