3. URI와 웹 브라우저 요청 흐름
3.1 URI
- scheme://[userinfo@]host[:port][/path][?query][#fragment]
- 쿼리, 파라미터
3.2. 웹브라우저 요청 흐름
HTTP 요청 메시지
GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com
애플리케이션 | 웹브라우저 (소켓 라이브러리)
OS | TCP/IP
network interface | LAN드라이버, LAN 장비
1. 웹브라우저가 http 메시지 생성
2. SOCKET 라이브러리 통해 전달
- A : TCT/IP 연결 (IP, PORT)
- B : 데이터 전달
3. TCP/IP 패킷 생성, TTP 메시지 포함
패킷
[ 출발지 IP,PORT + 목적지 IP, PORT
(요청메시지 ▼)
GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com ]
응답메시지
┌ HTTP/1.1 200 OK
Content-Type: text/html;charset=UTF-8
Content-Length: 3423
<html>
<body>...</body>
</html> ┘
4. HTTP 기본
4.1 모든 것이 HTTP
하이퍼텍스트 transfer protocol
[요즘] 모든 것에 http 에 담아서 전달함 (데이터 , 이미지 등)
- http에 연결하는게 아니라면, tcp에 연결해서
기반 프로토콜
TCP : HTTP/1.1 , HTTP/2
UDP : HTTP/3
- 현재 HTTP/1.1 주로 사용, 이외 점점 증가
▶ 확인방법
개발자도구 - Network - protocol 에서 http/1.1 , h2 = http2 , http3 = http3
★ http 1.1 의 스펙을 잘 알면 된다
무상태 프로토콜 (Stateful, StateLess 차이)
Stateful : 상태유지
ex) 점원이 바뀌지않음. (점원 바뀌면 본인원하는 정보없음. 컨텍스트 문맥없음 -> 변경전 미리알려줘야함)
노트북 얼마인가요? -> 2개 구매하겠습니다 -> 신용카드로 결제하겠습니다.
- [정보를 서버가 저장]
- 중간에 서버가 죽으면 clinet1은 서버 1부터 다시해야함
StateLess : 무상태
- 서버가 Client 상태 보존X
ex) 점원이 바뀜. 이거얼마에요? -> 이거얼마에요? 다시물어보고 점원은 히스토리를 모름.
상태 바뀌어도 문제없음. 이전 내용 계속 데이터 가지고 있기 때문
노트북 얼마인가요? -> 노트북 2개 구매하겠습니다 -> 노트북 2개 신용카드로 구매하겠습니다
- 갑자기 클라이언트 요청이 증가해도 서버 대거 투입 가능 (급 고객 증가 시 점원 대거투입가능)
- 응답 서버 쉽게 바꿀수있음 -> 무한 서버 증설 가능
- [ 정보를 클라이언트가 가지고 요청 ]
- 서버 1 장애나면 중계서버가 그냥 서버2로 보냄
- 스케일 아웃 가능
*실무 한계
단점 1: 모든 것을 무상태로 설계 할 수 있는 것도, 없는 것도 있음
설정 가능 - 상태 유지가 필요없는 것 : ex) 이벤트 소개 페이지 (상태유지필요없는 것)
설정 어려운 것 - 상태 유지가 필요한 것 : ex) 로그인 (사용자가 로그인 했다는 정보를 유지 해야함 - 브라우저의 쿠키, 서버의 세션 등 이용 -> 서버 날아가면 세션 날아가게되어 한계가 있다)
=> 상태 유지는 최소한만 사용, 어쩔수 없을 때만 사용해야한다
단점2 : 데이터를 너무 많이 보내아함 ( 노트북 / 2대 / 신용카드 )
비연결성
연결을 유지해야 하는 모델 : c1 c2 c3 s1 일때, c1-s1 , c2 c3 서버 유지하는 자원이 늘어남 (필요없을 때도)
연결을 유지하지 않는 모델 : 받고 바로 끊음. 최소한 자원 사용
HTTP는 연결 유지X (기본)
- 필요한 것만 연결 후 끊어버림. 수천명 사용해도 실제 처리 요청은 많이없음.
단점
- 검색하다가 중간에 보고 다음페이지 또 새로넘어감 => TCP/IP 연결을 새로 맺어야함 (3 way handshake 시간추가됨)
- 웹브라우저 요청 시 , html 뿐아닌 css, 이미지 등 수많은 자원 함께 다운
해결
- 지금은 http 지속 연결(persistent connections)로 문제 해결 (http 2, 3 에서 더 많은 최적화
HTTP 초기
1요청당 1응답 후 바로 끊음
연결 - 몇십초 유지 . 쭉 다 받고나서 이후 종료.
스테이트리스를 기억해야함
*서버 개발자들이 어려워하는 업무 : 같은 시간에 딱 맞춰 발생하는 대용량 트래픽 (ex. 티켓팅, 수강신청, 선착순 이벤트)
-> 최대한 스테이트리스하게 짜야함.
로그인 (정적) - 뭐라다 보다가 누르도록 -> 이벤트
HTTP 메시지
Stateful : 상태유지
[ HTTP 메시지 구조 ]
- empty line 공백 라인 (CRLF) 꼭필요함
HTTP 요청 메시지
시작라인 | 헤더 | 공백 라인
HTTP 응답 메시지
시작라인 | 헤더 | 공백 라인 | 메시지 body
1. 시작 라인
요청메시지 (request-line)
- start-line = request-line | status-line
- request-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)
http 메서드 path(요청대상) HTTP version
(GET:조회) (/search?q=hello?hl=ko)
① HTTP 메서드
- 서버가 수행할 동작 지정
- 종류 : GET, POST, PUT, DELETE
GET : 리소스 조회. 서버에게 리소스 달라고 함
POST : 요청 내역 처리. 리소스에 데이터 줄게 네가 처리해줘
DELETE : 삭제해줘
② 요청 대상 (절대경로[?쿼리])
"/"로 시작하는경로
③ HTTP 버전
응답메시지 (status-line) : HTTP/1.1 200 OK
- start-line = request-line | status-line
- status-line = HTTP-version SP status-code SP reason-phrase CRLF //SP : 스페이스
HTTP 버전 HTTP 상태 코드 이유 문구
200, 400(클), 500(서버) 사람이 이해할 수 있는 짧은 상태 코드 설명 글
HTTP 헤더
OWS 띄어쓰기해도 안 해도 괜찮음
Host: www.google.com
field-name: field-value
용도
- HTTP 전송에 필요한 모든 부가정보 담김
- ex) 메시지 바디의 내용, 크기, 압축여부, 인증, 요청클라이언트(브라우저) 정보, 서버 애플리케이션 정보, 캐시 관리 정보 등
HTTP 메시지 바디
- 실제 전송할 데이터
- HTML, 이미지, JSON 등 byte로 표현할 수 있는 모든 데이터 전송 가능
정리)
http2, 3 =은 http/1.1 + 성능
단순함. 확장가능
'언어 > HTTP' 카테고리의 다른 글
| 렌더링 (0) | 2025.03.24 |
|---|---|
| 모든 개발자를 위한 HTTP 웹 기본 지식 (6) (0) | 2024.11.07 |
| 모든 개발자를 위한 HTTP 웹 기본 지식 (7 - 中) (0) | 2024.11.04 |
| 모든 개발자를 위한 HTTP 웹 기본 지식 ( 5 ) (9) | 2024.11.04 |
