[Computer Network] Chap10. HTTP & SIP

 

 

 

 

 

10. HTTP & SIP

* HTTP/1.1

– HTTP client는 웹 브라우저 / 밑에 TCP를 까는 것을 전제로 한 것

- 프로토콜을 단순화 한 것 (에러 검출 및 복구 따위 X, 그건 TCP가 알아서 하겠지)

 

* Resource

1. Static content - HTTP request가 T0에 도착했을 때, T0 이전에 이미 컨텐츠가 만들어져 있으면 static 

- file system, 이미 만들어져 있는 비디오 클립 (유튜브, 넷플릭스) // DB에 들어있는 정보

2. Dynamic content 

- HTTP 리퀘스트가 올라가면서 T0 이후에, 그 안에 은행 계정, 인증번호 등을 통해 서버가 계산할 때

- 현재 주가 등 미리 계산할 수 X / 지금 만들어야 하는 이것들이 dynamic contents // by Logic server

 

- 이메일 컨텐츠에 대한 전통적인 프로토콜 MIME (Multipurpose Internet Mail Extensions) 

- TCP는 bit 단위, HTTP는 byte 단위 - 심지어 눈으로 읽을 수 있어 text base

 

- URI – Uniform Resource Identifier

- URN – name / URL – location (위치 정보를 통해 파일을 인식하는 것, 현재 사용하는 방식) 

 

* Transaction

– HTTP 클라이언트와 서버 사이의 request, response 과정 by HTTP methods 

- HTTP messages ex) GET _ request method (file을 주세요) / root 밑의 정확한 위치.gif 를 보낸다. 

- HTTP 메세지 안에도 HOST 주소를 씀 / 이미 IP에 있으나 굳이 2번 쓴다. 

 

- HTTP 4대 methods (request)

1. GET – 서버의 파일(리소스)을 요청, 가장 common – 서버로부터 파일을 가져오는 것 

2. PUT – 서버에 파일을 업로드, 과제 제출 -> 내가 준 파일을 루트 디렉토리 밑에 product-list.txt로 저장해

3. DELETE – 서버의 파일을 삭제 -> 200 OK -> 잘 지웠다.

4. POST – 값을 보내는 것, 검색창에 입력하는 텍스트 등 파일을 보내는 것이 X -> 서버는 받아서 로직을 돌림

-> Logic server에 params 전달할 때 or 프로그램과 프로그램이 정보를 주고 받을 때

 

- Status Code – return 값으로 3자리 숫자를 보냄 (response)

Ex) 200 – OK / 302 - redirection / 로그인 창 / 404 – not found 그 파일이 지워졌을 때, 즉 그 파일이 없음 

 

 

 

 

 

- User-agent를 통해 모바일 iOS에서 접속한 것인지, 어떤 브라우저를 쓰는지 파악함 (모질라 서버 등) 

+ 웹 브라우저의 성능을 높이는 방법 / 1. 기록 삭제 / 2. 캐쉬 이미지, 파일 삭제

+ 디스크까지 안 가고 CPU가 쓸 수 있도록 메모리에 미리 올려 두는 것 -> Cache / Last modified 연관 O

- TCP/IP - HTTP/1.1는 패킷이 유실되지 않길 바람 + 신뢰성 때문에 TCP 사용 -> 문제점 고스란히 안고 감

 

* HTTP/1.1의 연결 과정 

1. URL에 본인이 가고 싶은 곳 주소 입력 / 2. IP address를 얻기 위해 DNS 서버

3. Port number와 IP 주소를 통해 TCP 연결 + HTTP request를 보낸다 / 4. Response 가져오면 TCP 연결 해제

 

* Proxy Server 

- HTTP 브라우저와 서버 사이에 비공식적으로 존재하는 프록시 서버

- 중간에서 intercept 가로채서, 본인이 메세지를 읽는다.

 

- 웹 보안 -> DDoS 방지 / 블랙 리스트 사이트 접속 차단 및 기록 -> Application integration

- 거대한 파일을 앞단으로 가져옴, 최적화 / get request 자주 되는 파일을 미리 / performance optimization

- 서비스 로직을 중간에 만들 수 있다. -> HTTP request 살펴보고, 사양 낮은 단말기라면, 서버에서 받은 4K 해상도 컨텐츠를 proxy에서 다운 스케일링 하는 로직이 돈다 + 서버는 모름

 

* HTTP/2

- HTTP2.0 by Google SPDY

1. binary protocol - 텍스트를 다시 0과 1의 바이너리로 바꿈

2. Multiplexing - 논리적인 줄인 stream 개념을 도입 / 스트림은 독립적으로 송수신 가능

- 하나의 TCP 연결 안에, 어플리케이션이 집어넣는 스트림 개념 -> 여러 request response 독립적 처리 가능

3. 헤더 압축 – 반복적으로 사용되는 헤더를 헤더 테이블 내 인덱스로 처리 -> 헤더 크기를 80% 줄임

4. 우선순위 설정 – 병렬 처리 -> 스케줄링 이슈 -> 스트림 별 우선 순위 설정

5. 서버 푸시 - 서버가 본인이 필요한 정보를 push / 필요할 것 같은 리소스를 미리 서버가 내린다. 모바일은 X

 

1. binary protocol – 헤더 프레임과 데이터 프레임으로 쪼갬 -> 압축하고 01 비트 단위로 처리 + 중복 전송 X

 

2. Multiplexing / 다중화

– HTTP/1.1은 순서대로 와야 함 ex) 홈페이지의 80개 리소스 -> response도 순차적으로 와야 함 

- HTTP2는 독립적으로 동작하도록 만듦 -> 정해진 순서 없이, 선후관계 없이 동시 다발적으로 
response가 만들어지는 족족 클라이언트에게 보내기

- 하나의 TCP 줄(연결) 위에 여러 개의 스트림 / 큰 메세지 개념을 frame 단위로 쪼개

-> 즉 메세지를 다시 여러 개의 frame으로 찢음 – interleaving

- 스트림 1 ~ N 은 독립적으로 송수신 가능함

 

- 과거 편법 - TCP 줄을 여러 개 뚫음 -> 최대 8개 뚫었음 (속도 8배 증가 가능)

- HTTP2는 3개가 각자 스트림으로 쪼개져서 가능 

+ 에러가 없고, 속도가 빠른 네트워크에서는 HTTP/2가 1보다 좋다. (전제 조건 중요!)

 

3. Header Compression 헤더 압축 

1. 우리 모두 테이블을 동일하게 갖고 있을 테니, 큰 글자를 숫자로 바꿈 -> GET 대신 2 즉 index 값을 보내

-> 서로 합의에 의해 상수 값을 주고 받음 - 헤더 부분의 사이즈가 확 줄어듦

2. static table 밑에 추가되는 dynamic table - 내가 이 서버에 붙었을 때 서로 주고 받는 정보는 동적으로 추가

3. 허프만 코딩 - 변화된 값만 추출해서 보내는 압축 방식 / original에서 나는 변경된 값만 보내 (델타 값)

 

4. Server Push – 클라이언트가 요청하기 전, 필요할 것 같은 리소스를 서버가 먼저 전송

- import 하는 모듈들의 사이즈가 큼 - HTML 그제서야 가져와서 실시간으로 분석하고 보여주는 것이 일반적임

-> 내가 미리 컨텐츠 파일을 보낼 테니까 미리 처리해라

 

* HTTP/3

- HTTP/3 by Google QUIC

 

 

- TCP 성능 저하 - slow start + 톱니바퀴

- HTTP/2더라도, single TCP 연결에서 loss 발생 -> 모든 스트림이 함께 성능 저하로 직행

- 이에 UDP base QUIC 등장 -> OSI 7 layer의 4계층이야!

 

* Head of Line blocking 문제 In HTTP/2

- HTTP2는 에러가 발생하는 네트워크라면, 성능이 떨어질 여지가 있다. 여전히 TCP의 문제점 O

- like 이동 통신, 차라리 HTTP/1.1의 TCP 8줄 뚫는게 낫다는 거야

 

- QUIC은 TCP를 대체하는 범용 목적의 4계층 전송 계층 통신 프로토콜

- UDP 위에서 new protocol QUIC -> 커널 안 X, 커널 위의 application layer

- HTTP2와 마찬가지로 stream multiplexing 개념 사용

- 일반적인 TCP + TLS (전송 계층 보안) 보다 QUIC -> 훨씬 빠르다 fast establishment

 

- 0-RTT - 퀵 연결이 나가면서 동시에 HTTP request가 나감 -> 연결 요청과 동시에 데이터를 쏨

- 클라이언트와 서버가 이미 인증절차 거쳤으면, 지난 번에 왔으니까, 그냥 데이터 보내

- 첫번째 HTTP 응답이 사용자에게 오는 시간을 줄이는 것

 

- HTTP3는 HTTP over QUIC을 표준화 한 것 -> 성능 개선 

- contents delivery network CDN – 유튜브, 넷플릭스 or 캐쉬 서버 업체들

-> 어플리케이션은 그대로, 밑에 깔리는 소프트웨어만 퀵으로 바꿨는데, 속도(성능)가 증가한 것

 

- 시작은 서버 투 서버 / 에러 날 필요 X, 매우 빠른 상황 -> UDP도 충분하겠네 (이게 구글 퀵 개발의 start)

- 처음에는 QUIC 성능 X -> TCP는 A급 개발자, UDP는 후진 코드 -> 리눅스 UDP 코드 개선하여 성능 향상

 

* SIP

- session initiation protocol, 세션을 만드는 프로토콜

-> heavily inspired by HTTP -> text-based, request-response protocol – 사람이 읽을 수 있음 

- 줌, 구글미트, 카카오 전화 -> 채팅 방을 만들고 없앨 때 / 과거 유선 전화 방식에서 나온 오래된 프로토콜

 

* 연결설정 및 해제 과정 

- SIP INVITE 연결 설정 – 200 OK / SIP ACK 연결 설정 다 되면 본격적으로 주고 받음 / SIP BYE 연결 해제

 

* 메신저 서비스 예시 - delivered (앱에게 메세지를 잘 보냈다) / displayed (앱이 화면에 잘 뿌렸다)

 

 

 

 

* 다른 웹 기술들

1. WebRTC

- 구글이 만든 기술, 웹 기반으로 실시간 통신 p2p real time communication

- 웹 브라우저 안에 들어가서 화상 프로그램 / 화상회의, 전화, 채팅을 위한 모든 기술이 다 들어가 있음

 

* STUN / Signaling / TURN Server

1. 유무선 공유기의 주소는 private IP address / STUN 서버를 통해 본인의 public IP address를 알려줌 

-> 즉 NAT/PAT를 통과하며 바뀐 주소를 상대방에게 알려줌

2. Signaling Server – SDP, ICE 등 시그널링 서버를 통해 각 디바이스의 정보를 주고 받아 P2P 통신

3. TURN server – 클라이언트와 서버 간 데이터 전송을 중계 / 데이터 전송 역할, 미디어 서버 

 

1. 인원 수가 늘어나면 서버 비용이 청구됨 -> N에 대한 숫자를 제한 / 결국 비지니스 모델은 서버! 

2. 서버가 해상도에 맞추어 transcoding / 3. 영상 녹화 및 저장, 다운로드 등 부가 기능

 

2. WebXR/WebVR – 웹 브라우저로 실어 나르는 Mixed Reality, WebXR (모질라 재단)

3. asm.js  / assembly + JavaScript -> 망함, 웹 기술은 구글 X, 모질라 재단

- 행렬 물리 수학 -> 이게 결국 성능을 발목잡음 -> 그냥 C/Cpp로 짠 프로그램을 웹 브라우저 위에서 올리자

- JS - JAVA는Virtual machine 위에서 실행됨

 

4. WASM - Web Assembly

- 모든 언어에 대한 범용의 virtual machine / compile / build만 하면 됨

- target option - web assembly (.wat) / platform independent

- 웹 어셈블리 위에서 돌아가는 파이썬 complier도 있음! 서버와 클라이언트 사이의 경계가 무너지고 있다.

- 데이터 센터와도 연관 - 필요할 때 필요한 만큼 쓰고 반납하는 클라우드, 쿠버네티스, 컨테이너 기술 

- 브라우저와 서버쪽에서 혁명적인 변화를 일으키고 있다.

 

5. WebGPU

- 브라우저가 왜 하드웨어를 건드리면 안되지? 보안보다 중요한 것은 성능 아닐까?

- 게임 물리엔진, GPU 병렬처리, 데이터 처리 등 브라우저가 하드웨어 자원을 직접 access

- 웹기반 서비스들의 성능 향상 / 크롬 브라우저 위에서 다 돌아가는 것

 

6. Solid – WWW 웹의 아버지 팀 버나스 리 경 -> 개인이 권한을 갖자