[이것이 백엔드 개발이다/한빛미디어] CH08. 서버와 클라이언트의 약속, HTTP (1)

   HTTP 트랜잭션   

: 'HTTP 요청 + 응답' 묶음

 

클라이언트 : HTTP 요청 (웹 서비스 사용) -> 웹 브라우저

서버           : HTTP 응답 (웹 서비스 제공)

 

'HTTP 트랜잭션'은 어떻게 확인 가능한가 ?

= 웹 브라우저 '개발자 도구'에서 !

 

HTTP 트랜잭션 : [Network] 탭에서 확인

개발자 도구를 켜기 전 발생한 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 통신 가능.