[Network] 모든 개발자를 위한 HTTP 웹 기본 지식 - 1

https://www.inflearn.com/course/http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC/

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

 

ㅇ 인터넷 네트워크

ㅁ 인터넷 통신 & IP (인터넷 프로토콜)

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

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

 

-IP 패킷 정보

: 출발지 IP 정보, 목적지 IP 정보, 내용

- 받은 서버는 response 패킷을 전함

 

-IP 프로토콜의 한계

> 비연결성 : 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송

> 비신뢰성 : 중간에 패킷이 사라지면? 패킷이 순서대로 안오면?

> 프로그램 구분 : 같은 IP를 사용하는 서버에서 통신하는 어플리케이션이 둘 이상이면?

> 패킷 전달 순서 문제 발생 : 나중에 보낸게 먼저 도착할수도?

>> 해결책은 TCP / UDP

 

ㅁ TCP, UDP

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

> 네트워크 인터페이스 계층 -> 인터넷 계층 IP -> 전송 계층 TCP, UDP -> 어플리케이션 계층 HTTP, FTP

- 메시지 생성 및 전달 과정

1. 프로그램이 Hello, World! 메시지 생성

2. SOCKET 라이브러리를 통해 전달

3. TCP 정보 생성, 메시지 데이터 포함

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

5. Ethernet frame(장비의 물리적인 주소) 포함되어 전달 

 

- TCP 세그먼트 : 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보 등

 

- TCP 특징

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

> 데이터 전달 보증

> 순서 보장 

 - 잘못된 경우, 다시 보내라고 함 (TCP 세그먼트 활용하여 순서 체크)

> 신뢰할 수 있는 프로토콜

 

- TCP 3 way handshake

1. SYN

2. SYN+ACK

3. ACK

 => connect, 연결 과정 ( 연결성 체크 과정 )

4. 데이터 전송

 

- UDP 특징

> IP와 거의 같다. + PORT + 체크섬 정도만 추가

 - 왜 쓸까? TCP는 handshake 과정이 오래 걸림, 단순히 port, 체크섬을 통해 용도 구별 가능

> 어플리케이션에서 추가 작업 필요

 

 

ㅁ PORT

- 같은 IP 내에서 프로세스 구분

- 0 ~ 65535 할당 가능

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

 

ㅁ DNS
- IP 는 기억하기 어렵고, 변경될 수 있다.

- 도메인 주소를 DNS 서버에 query 하면 해당하는 IP를 return 해준다.

 

 

ㅇ URI와 웹 브라우저 요청 흐름

ㅁ URI (Uniform Resource Identifier)

- URI ? URL? URN?

- URI는 로케이터 (Locator), 이름 (name) 또는 둘 다 추가로 분류할 수 있다.

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

 > 앞으로 URI를 URL과 같은 의미로 표시

- URL 전체 문법

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

 

ㅁ 웹 브라우저 요청 흐름

- 패스 및 쿼리 로 메시지 생성

 

 

ㅇ HTTP 기본

ㅁ 모든 것이 HTTP

- HyperText Transfer Protocol

- HTTP 메시지에 모든 것을 전송

- HTTP/1.1 1997년에 나왔는데, 가장 많이 사용, 우리에게 가장 중요한 버전

 > 2,3는 성능 개선 (TCP : 1.1 , 2 / UDP : 3 )  - HTTP/3은 TCP 대신 UDP 사용

- HTTP 특징

1. 클라이언트 서버 구조

2. 무상태 프로토콜 (스테이트 리스), 비연결성

3. HTTP 메시지

4. 단순함, 확장 가능

 

ㅁ 클라이언트 서버 구조

- Request Response 구조

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

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

 

ㅁ Stateful, Stateless

- 상태유지 : 중간에 다른 점원으로 바뀌면 안된다.

- 무상태 : 중간에 다른 점원으로 바뀌어도 된다. 

 > 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.

 > 무상태는 응답서버를 쉽게 바꿀 수 있다. -> 무한한 서버 증설 가능

- 실무한계

> 모든 것을 무상태로 설계 할 수 있는 경우도 있고 없는 경우도 있다.

> 무상태 : 로그인이 필요 없는 단순한 서비스 소개 화면

> 상태유지 : 로그인

> 로그인한 사용자의 경우 로그인 했다는 상태를 서버에 유지

 

ㅁ 비연결성

- HTTP는 기본이 연결을 유지하지 않는 모델

- 일반적으로 초 단위의 이하의 빠른 속도로 응답

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

 예) 웹 브라우저에서 계속 연속해서 검색 버튼을 누르지는 않는다.

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

 

- 한계와 극복

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

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

> 지금은 HTTP 지속 연결 (Persistent Connections)로 문제 해결 - keep alive

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

- 이벤트 등으로 수많은 request가 동시간대에 몰릴때에도 stateless가 좋다.

 > 앞에 html을 두어서 사람들이 조금 보게해서 누른다던지.. 기획적으로 푸는 방법

 

ㅁ HTTP 메시지

-  HTTP 메시지 구조

> start-line 시작라인

 > request-line

 : http-method / 요청 메시지- 요청 대상 / http 버전

 > status-line

 : http 버전 / http 상태코드 ( 200: 성공 / 400 : 클라이언트 요청 오류 / 500 : 서버 내부 오류) / 이유 문구

> header 헤더

 : field-name":" OWS Field-value OWS (OWS: 띄어쓰기 허용)

 : HTTP 전송에 필요한 모든 부가정보 (ex: 메시지 바디 내용, 메시지 바디 크기, 압축, 인증, 요청 클라이언트(브라우저) 정보, 캐시 등)

> empty line 공백 라인 (CRLF) - 필수

> message body

 : 실제 전송할 데이터

 : 바이트로 표현할수있는 모든데이터가 해당함

HTTP 메시지 구조