모든 개발자를 위한 HTTP 웹 기본 지식을 듣고 정리한 내용입니다.
네트워크의 흐름
IP 프로토콜을 보완한 것이 TCP와 UDP
IP 프로토콜은
- 도착지와 목적지의 정보를 갖고 있다
- 비연결성
- 비신뢰성
IP 프로토콜의 문제점이란?
- 순서가 뒤죽박죽으로 도달할 수 있다.
- 패킷이 소실될 수 있다.
- 상대방의 연결이 끊겨있는데도 보내려고 할 수 있다
패킷이라는 단어
패키지+버킷의 합성어
전송 과정
- 데이터를 만들면 (ex.채팅 메시지)
- 소켓 라이브러리로 전달되고
- TCP 정보를 생성, 메시지 데이터 포함해서 내리고
- IP 패킷 생성, TCP 데이터를 포함해서 내리고
- 랜카드로 나갈 땐 이더넷 프레임을 포함해서 나간다
TCP
3 way handshake
- SYN : 접속요청. 연결되어있나 확인하는 것
- SYN+ACK : 요청 수락!
- ACK : 그렇구나! 데이터를 보낸다! (요즘에는 데이터전송도 이 단계에서 같이)
물론 논리적으로만 연결된 것이다!
데이터 전달 보증
데이터 전달한다 - 잘 받았다 라는 신호가 있으니까
순서 보장
만약 순서가 제대로 도착하지 않았다면 다시 보내라고 하거나 하는 등의 처리를 한다.
따라서 신뢰할 수 있는 프로토콜이 TCP!
UDP
하얀 도화지에 비유된다.
전달 보증 X
순서 보장 X
이처럼 IP와 거의 같은데, Port번호와 체크섬이 추가된다.
메시지가 제대로 왔는지 검증해주는 요소이다!
- TCP는 다 좋지만 3way 핸드쉐이크를 하는데 시간도 걸리고, 기타 붙는 게 많으니 전송 속도도 더 걸리게 된다.
- 그러나 이미 인터넷은 TCP를 기반으로 쓰이기 때문에 추가 최적화가 불가.
- 그러나 UDP는 아무것도 되어있지 않아서 이걸 바탕으로 최적화를 할 수 있다!
Port
IP는 목적지 서버를 찾는거
포트는 서버 안에서 돌아가는 애플리케이션을 구분하는 것 (즉, 같은 IP내에서 프로세스를 구분하는 것!)
패킷의 구성
따라서 패킷은 출발지와 목적지 IP&Port, 전송데이터 등등으로 구성된다
비유
IP가 아파트면 Port는 몇동 몇호다!
할당 가능한 포트 : 0~65535
16비트 2^16이라서 (65536) 65535까지 사용가능
잘 알려진 포트 : 0~1023
사용하지 않는 것이 좋다!
HTTP는 80이고 HTTPS는 443, FTP는 20,21
DNS
필요한 이유
- IP는 바뀔 수 있다.
- 기억하기 힘든 문제도 해결할 수 있다.
URI와 웹 브라우저 요청 흐름
URI : uniform resource identifier
리소스를 식별하는 통합된 방법.
uniform
리소스를 식별하는 통일된 방식
resource
리소스 = 자원
URI로 식별할 수 있는 그 모든 것.
교통정보, 파일 등등 (제한없음)
identifier
다른 항목과 구분하는데 필요한 정보
URI는 로케이터locator, 이름name 또는 둘 다 추가로 분류될 수 있다.
자원을 식별하는 방법이 URI인데, 이 안에 URL(리소스 위치)과 URN(리소스 이름)이 있는 것이다.
URL locator 리소스가 있는 위치를 지정
우리가 주소창에 입력하는 그것!
URN name 리소스에 이름을 부여
urn:isbn:898724032
URN은 찾기가 어려워서 사장되고 URL을 쓰는 것!
HTTP
클라이언트 서버 구조
기본적으로 클라이언트는 리퀘스트를 보내고 서버가 리스폰스를 보낼때까지 기다렸다가 동작한다
클라이언트와 서버가 분리되어있다는 게 중요하다 (원래 예전에는 개념이 분리되어있지 않았다.)
비즈니스 로직과 데이터는 서버에 몰아넣고, 클라이언트는 UI에 집중하게 한다.
예를 들어 클라이언트가 안드로이드라면 그냥 안드로이드 UI를 그리는 데 집중하면 된다. 서버를 증설해야하면 클라이언트쪽은 전혀 신경쓰지 않아도 되는 것
이런 식으로 양쪽이 독립적으로 진화할 수 있다는 게 중요하다!
무상태 프로토콜
stateful
중간에 다른 점원으로 바뀌면 점원들끼리 정보를 공유하지 않기에 문제가 생기는 것.
따라서 항상 같은 서버가 유지되어야 한다. = 클라A는 계속 서버1이랑만 통신해야한다
stateless = 무상태
각각 다른 점원이 응대해도 점원들끼리 정보를 공유하기에 중간에 다른 점원으로 바뀌어도 문제가 없다.
→ 갑자기 고객이 증가해도 점원을 대거 투입할 수 있다.
→ 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.
이것이 클라이언트 서버 아키텍처!
따라서 무상태로 하면 응답 서버를 쉽게 바꿀 수 있으니 무한한 서버 증설이 가능해진다.
클라이언트가 요청 데이터를 전부 담아서 보내는 것이다.
애플리케이션 설계는 대부분 무상태로하고 최소한만 상태유지로 한다는 사실만 기억하자!
비연결성
연결을 유지하는 모델
연결을 계속 유지하면 서버의 자원이 소모된다 (클라이언트가 놀고 있어도!)
연결을 유지하지 않는 모델
요청에 응답하고 바로 연결 끝냄. 최소한의 자원을 유지하는 서버
HTTP는 기본적으로 연결 유지하지 않는 모델!
웹 브라우저에서 수천명이 서비스를 사용한다해도 실제 서버에서 동시 처리하는 요청(ex.검색)은 매우 적다
따라서 서버 자원을 매우 효율적으로 사용할 수 있다
단점
TCP/IP 연결을 새로 맺어야 한다 → 그럼 3way handshake 시간이 추가된다
웹브라우저로 사이트를 요청하면 수많은 자원이 함께 다운로드 된다
HTTP 지속 연결
요청 하고 다 받고나서 종료하는 것.
서버 개발자들이 어려워하는 업무는 같은 시간에 대용량 트래픽 발생하는 사례
(ex.선착순 이벤트, 명절 HTX 예약)
어떻게든 머리를 쥐어짜서 최대한 스테이스리스하게 설계해야 한다.
그래서 보통 이벤트 첫 페이지는 정적 페이지를 두는 이유 ← 이 안에서 보다가 누르게 하기 위함
HTTP의 특징
단순함! 스펙시트도 단순하다
이처럼 크게 성공하는 건 단순하지만 확장성이 좋은 기술인 것 같다
지금은 JSON이든 파일이든 모든 걸 다 HTTP로 전송하는 HTTP 시대!
