[이것이 백엔드 개발이다/한빛미디어] CH08. 서버와 클라이언트의 약속, HTTP (1)
HTTP 트랜잭션
: 'HTTP 요청 + 응답' 묶음
클라이언트 : HTTP 요청 (웹 서비스 사용) -> 웹 브라우저
서버 : HTTP 응답 (웹 서비스 제공)
'HTTP 트랜잭션'은 어떻게 확인 가능한가 ?
= 웹 브라우저 '개발자 도구'에서 !
개발자 도구를 켜기 전 발생한 HTTP 트랜잭션은 기록되지 않는다.
반드시 '개발자 도구'를 킨 다음, 웹 사이트에 접속할 것 !
Network 탭 역할
- Headers (헤더)
: HTTP 헤더 정보.
: 요청 헤더 & 응답 헤더 나눠 보기 가능.
- Payload
: 클라이언트에서 서버로 보내는 요청 데이터의 본문 부분.
: 요청 바디 있는 경우 확인 가능.
: ex. 폼 데이터 전송, AJAX 요청 등 확인 가능.
( ! HTTP 요청은 '헤더', '바디'로 나뉜다. )
- Preview (미리보기)
: 응답 바디에 포함된 데이터 -> 미리보기 제공.
: ex. 이미지 파일, HTML 문서를 웹 브라우저 형태로 미리보기.
- Response (응답)
: 응답 바디에 포함된 데이터 -> 있는 그대로 제공.
: ex. JSON 문자열, HTML 문서
( ! 이미지 파일 : 'This request has no response data available.' 문구 표시 )
웹 브라우저 접속 시, 왜 여러 번의 HTTP 트랜잭션이 발생했나 ?
웹 브라우저는 '응답'으로 온 'HTTP 페이지에 포함된 이미지, JS, CSS에 대한 요청'을 자동으로 수행하기 때문.
-> 자동 요청해야 원활환 웹 서핑 가능.
( ! Postman 클라이언트 사용 -> HTTP 트랜잭션 1번만 발생했을 것. )
트랜잭션이란 ?
1. (일반) 쪼개질 수 없는 처리
2. (HTTP) 'HTTP 요청 + 응답'이 하나의 '묶음'으로 이루어짐
[A 계좌 -> B 계좌 '이체' 기능]
1. A 계좌) 일정 금액 차감 연산 실행
2. B 계좌) 일정 금액 덧셈 연산 실행
! 문제 발생
2번에서 문제 발생 시, A 계좌 돈 증발 !
-> 1번으로 되돌려야 할 필요가 있음.
트랜잭셔널(Transactional)한 처리
2가지 이상 연산 실행 시,
'모두 실행 상태' or '다 실행 X 상태' 만드는 것.
( ! 중간에 멈춘 상태 X )
=> '원자성(Atomic)' : 쪼개질 수 없는 특징
HTTP
: HyperText Transfer Protocol.
: 정보 전송 통신 규약(Protocol).
HTTP/1.1
: 프로토콜이 안정적으로 자리 잡은 버전.
: 가장 널리 사용됨.
HTTP/2
: HTTP/1.1에서 빠르게 전환되는 중
HTTP/1.1 특징
1. 클라이언트 요청 -> HTTP 트랜잭션 시작
- 클라이언트가 먼저 요청 시작해야.
- 한계 : 서버에서 데이터 줘야 할 때, 실시간으로 줄 수 없음
( ! 해결 : 웹 소켓 기술 도입)
2. 상태 안가짐
- 이전 HTTP 트랜잭션 & 다음 HTTP 트랜잭션 사이 연관 관계 X.
- 무상태성 : 동일 클라이언트 -> 지금, 잠시 후 요청 건 구분 불가.
( ! 별도 사용자 식별 수단 통한 구분 가능 : 쿠키, 세션, 토큰 등)
3. 비연결성 O
( ! 두 주체 연결 위해 '소켓'을 서로 연결하는 과정 필요(네트워크 연결) : 커넥션 )
장점)
- 클라이언트 & 서버 자원 -> 효율적 사용 가능.
단점)
- 매번 HTTP 트랜잭션마다 연결, 끊음 과정 추가.
- 오버헤드 : 매 연결마다 조금씩 성능상 손해.
오버헤드 완전 없애기 가능 ?
[오버헤드 줄이는 법]
클라이언트 - 서버 간 교환 HTTP 메시지 남아 있을 경우,
연결 끊지 않고 그대로 사용.
[트레이드 오프 (Trade-off)]
'한 쪽에서 오버헤드 줄임 -> 다른 쪽에서 문제 발생'
위 상황 대처 위해 트레이드 오프 적절히 해야 함.
- ex. HTTP -> 클라이언트, 서버 사이 커넥션 끊는 비연결 사용 (서버, 자원 적절 사용 위함)
* [컨텍스트 스위칭]
운영체제 ->
하나의 프로세스(스레드)에서 다른 프로세스(스레드)로 실행 흐름 옮겨 가는 과정에서 발생.
* (HTTP 제외) 오버헤드 발생
1. 데이터를 파일에 읽고 쓰는 과정
: 파일 열고 닫는 과정
2. DB에 쿼리 날릴 때
: 커넥션 획득 후 반납
4. 사람 친화 프로토콜
- 사람이 읽을 수 있는 형태로 헤더 주고받음.
- 단, HTTPS : 헤더 암호화 이유로 바로 알아볼 수 없음.
[한계]
1. 웹 브라우저 접속 시 HTML 페이지 다운로드 -> 포함된 CSS, JS, 이미지 파일 연달아 받는 상황
파이프라이닝 방법 : 하나의 커넥션 통해 요청, 응답 처리하도록 개선.
그러나, 제약 : 요청 순서와 동일 응답 와야 함
-> 앞 요청 처리 늦어지면, 뒤 요청 처리도 늦어진다는 문제 발생
2. 사람 친화 프로토콜
- 헤더 사이즈 키움
- 파싱(Parsing)하는 데 비효율적, 낮은 성능
- TCP 특성 : 느린 시작
TCP (Transmission Control Protocol) 느린 시작 원인
: 처음 요청하여 실패 가능성 있는 요청에게
네트워크 대역폭 낭비 안하도록 생성
-> 전체적 네트워크 효율 높이기 위함
HTTP/2 특징
1. 1 커넥션 : N 요청 -> 동시 다중 처리.
- HTTP/1.1 한계 1번 개선
2. 헤더 압축.
- HTTP/1.1 한계 2번 개선
3. 서버 예상 요청 -> 미리 클라이언트에 전송.
- 다중화와 비슷하게 반드시 연달아 제공되는 파일 있을 시
- 서버 푸시 (Server Push)
서버 푸시 (Server Push)
: HTML 요청 시, 포함 요청 예상 CSS, JS, 이미지 파일들
요청 오기 전 서버에서 클라이언트에게 보냄.
! 모든 상황에서 좋은 방법은 아님
클라이언트가 실제 필요 X 콘텐츠 푸시 -> 불필요한 네트워크 대역폭 낭비
HTTP/3 특징
1. 'QUIC'라는 UDP 사용 프로토콜.
*QUIC (Quick UDP Internet Connections)
A) 'HTTP 트랜잭션에는 네트워크상에서 커넥션 맺는 과정' ( : TCP의 핸드쉐이킹 ) 필요.
장점) TCP : 안전히 두 주체 간 정보 교환 가능.
단점) TCP Handshaking 자체가 오버헤드.
그러나, UDP : 핸드쉐이킹 과정 없음.
B) 네트워크 헤더에서도 차이 있음.
TCP 헤더 : 안정적 데이터 전송 위해 여러 가지 필드 가지고 있음.
UDP 헤더 : 포트(출발지, 목적지), 데이터 길이, 체크섬만 갖고 있음.
체크섬 (Checksum)
: 데이터 전송 시 오류 발생했는지 검증하기 위한 값.
-> UDP 프로토콜 위 HTTP 통신에서 필요한 부분만 추가로 구현 시,
효율적, 빠르게 HTTP 통신 가능.