[Computer Networks] L10.HTTP

• toc {:toc}

Notice

Computer Networks 글은 경희대학교 소프트웨어융합대학 이성원 교수님의 [컴퓨터 네트워크 CSE302] 수업을 기반으로 정리한 내용입니다.

HTTP

• 4계층 이상이나 어느 계층인지는 명확히 할 수는 없다.
• HTTP 1.1, HTTP 2가 TCP를 사용하도록 했기 때문에 TCP를 사용한다.
• HTTP 3(유튜브)부터는 TCP를 사용하지 않고, 새로운 트랜스포트 계층의 통신 프로토콜을 사용한다.

HTTP/1.1

• Web Client and Servers

• HTTP : 웹 서버와 웹 브라우저(클라이언트) 사이의 정보를 주고 받는 프로토콜의 이름
• HTML : HTTP가 전송하는 정보들 중 하나이다.
• 4계층 위이기는 하나, 구체적으로 정의하지 않는다.
• request를 하면 전송, 없어지면 TCP가 오류 검출, 처리.

Resources

• 파일이 정적인지, 동적인지를 묻는 것이 아니라 request를 받기 전에 이미 만들어져 있는지를 묻는다.

• Static : request를 받기 전에 만들어져 있는 content

• Dynamic : request를 전송하면서 request 정보(인증, 계정 정보 등)를 받아 생성하는 content

• Media Types

  • MIME (Multipurpose Internet Mail Extensions)
  • Textual label

• HTTP 요청을 통해서 클라이언트가 이미지 파일을 달라고 요청한다.

• 서버는 Content-type: image(MIME type)/jpeg, Content-length가 담긴 데이터를 전송한다.

• TCP는 비트 단위로 처리되어 확인할 수 없었으나, HTTP는 눈으로 어떤 정보가 오고가는지를 알 수 있다. → HTTP의 문제점으로 발생한다.

• URI (Uniform Resource Identifier) : 추상적 개념.

  • Server resource name : 인터넷의 주소, 유일하게 구분된다. 인터넷 리소스의 위치를 나타낸다.

• URL (Uniform Resource Locator) : HTTP로 위치를 설명한다.

• URN (Uniform Resource Name) : HTTP로 유일한 이름을 가진 리소스를 가져온다.

Transactions

• 클라이언트는 / 를 통해 디렉토리를 구분하고 그 안에 있는 파일을 요청한다.

• 서버는 해당 위치로 이동해 확인하고 전송한다.

• HTTP method

• 여러 요청 명령어를 지원한다.

• 서버가 어떻게 행동해야 하는지를 나타낸다.

• GET : 서버로부터 클라이언트에 해당 리소스를 전송하라.

• PUT : 클라이언트로부터 해당 서버 리소스에 저장하라.

• DELETE : 서버에서 해당 리소스를 제거하라.

• POST : 서버 게이트웨이 App으로 클라이언트 데이터를 전송하라.

• HEAD : 리소스를 위한 응답으로부터 HTTP 헤더만 전송하라.

• Status codes

• 상태 코드를 포함하는 http 반환값이다.

  • 200 : OK
  • 302 : Redirect - A에 접속했을 때 화면이 B로 변경되는 경우(로그인 Google 연동)
  • 404 : Not Found

Messages

• Start line : 메소드 이름과 URL이름이 있는 한 줄

• Body : 파일이나 정보를 전송할 때 해당 데이터

• Request Header : 텍스트 파일 전부를 소화 가능, 언어는 en, fr만.

• Response Header : Content-type, Content-length

• Example

• Last-modified : 이전에 접속했던 곳을 다시 접속할 경우 캐쉬로 저장해두어 이전에 저장해둔 것을 사용한다. 때문에 마지막으로 수정된 날짜와 비교해서 이후 접속하는 경우 저장해둔 내용을 사용한다.

Connections

• Transport layer under HTTP

• 80 : 포트 번호

• host name에 대해 DNS를 통해 해당 IP 주소로 변환된다.

• 과정

  1. URL 입력
  2. DNS lookup → IP 주소로 변환
  3. TCP 연결 설정
  4. 연결 시 HTTP 요청/응답
  5. TCP 연결 해제

• TCP 연결에는 시간이 많이 걸리는데, 이를 구글은 DNS 서버의 시간을 줄이는 방식으로 연결 시간을 감소시켰다.

• 검색을 할 때 입력하는 시간보다 더 빠르게 DNS 서버에 lookup 하도록 만들었다. (질문)

• Proxy : 비공식적으로 존재하는 서버. 중간에서 요청을 가로채 메시지를 읽고 처리한다.
• 서버에 접근하려면 중간 기기를 건너야 한다.
• 클라이언트와 서버 사이에 위치한다.
• 웹 보안 : 접속하면 안되는 사이트를 접속하는 등 보안 사항을 위반 시 차단, 통보
• 성능 최적화 : 큰 크기의 파일을 서버와 가까운 위치로 이동시켜 멀리서 가지고 오지 않아도 되도록 만든다.
• Application 통합 : 중간에서 HTTP 요청을 가로채 서버로 주지 않는다. 프록시는 서버에서 데이터를 받아오고, 만약 단말기가 구식인 경우 서버로 받아온 데이터를 프록시 서버가 성능을 낮춰 단말기로 전송하는 방식.

HTTP/2

Binary protocol

Multiplexing

Overview

• Multiplexing : 하나의 TCP 연결 안에서 다수의 스트림(Stream)을 생성해 다수의 요청, 응답을 동시에 처리하는 방법
• HTTP 1.1 : 요청 1을 받는 경우 1에 대한 응답을 전송하는 것과 같이 요청 받은 순차적으로 전송한다. 특정 항목이 느리면 응답을 기다리는 모든 요청이 느려진다.
• HTTP 2.0 : 요청 각각에 대해 독립적으로 응답할 수 있도록 하는 방식

Connection

• TCP 연결은 하나만 한다.
• 스트림(Stream) : TCP 연결 안에 논리적인 여러 개의 줄
• Stream 각각이 동시다발적으로 송수신할 수 있도록 함으로써 요청 각각에 대해 응답할 수 있도록 만든다.
• 이로써 선후 관계 없이 요청/응답할 수 있다.

Comparison

• 동일하게 TCP 연결을 진행한다.

• Stream을 사용해 1~n 까지 설정해 독립적으로 송수신한다.

• TCP 연결은 하나이기 때문에 하나의 스트림의 데이터 전송량이 크다면 다른 스트림에 영향을 준다.

• 이를 방지하기 위해 하나의 파일을 여러 개의 프레임으로 쪼개 전송하여 공정성을 어느 정도 보장한다.

• 위 그림에서 HTTP 1.1의 경우 TCP를 3개를 연결하는 방식을 통해서 통신하는 것을 보인다. 최대 8개까지 연결해 사용했다.(CPU의 낭비 심했음)

• Priority

• 스트림 별로 우선 순위를 지정함으로써 중요한 리소스의 처리 지연을 방지한다.

Header Compression

• 헤더의 압축을 통해 더 작게, 더 빠르게 전송할 수 있도록 만들었다.
• 중간 테이블과 같이 각 내용에 대해 미리 각 테이블의 값이 어떤 값이 올 지를 설정해 놓는다. GET을 요청하는 경우 2를 전송해 더 압축된 데이터를 전송할 수 있다.
• 문자열에 해당하는 문자들을 숫자들로 전송하자.
• 동적 테이블은 테이블의 내용은 변화하지만, 상수값으로 서로 주고 받아야 하는 값(도메인 주소 등)을 설정하고 이를 숫자를 통해서 주고 받을 수 있도록 한다.
• 허프만 코딩 : 선형적으로 변화하는 값이 있다고 한다면 차이값만 전송함으로써 데이터를 압축하는 방식
  • 이미지를 가정해보자. 이미지 1과 10은 진짜 이미지.
  • 1과 10의 차이값으로 가짜 이미지 5를 만든다.
  • 가짜 이미지와 1과의 차이값으로 가짜 이미지 3을 만든다.
  • 다음의 방식을 통해서 가짜 이미지 2~9를 만든다.
  • 진짜 이미지는 데이터 값이 많지만, 가짜 이미지는 차이값만을 갖기 때문에 데이터 양이 적다.

Server Push

• 서버가 본인이 필요한 정보를 push 한다.
• HTTP 1.1의 경우 요청을 받아야 응답받는 형식이었다.
• HTTP 2.0을 통해서 클라이언트가 요청을 하지 않아도 필요가 예상되는 리소스를 서버가 먼저 전송하는 방식
• 사용자가 뉴스를 보고 next를 많이 누른다고 한다면 next를 누르는데 필요한 내용을 미리 보내어 next를 눌렀을 때 더 빠르게 응답을 주는 방식

HTTP/3

• TCP의 문제점

1. Slow Start 최초 연결 전송의 속도는 반드시 느리다.
2. 스트림 하나에서 프레임 손실이 발생하면 다른 스트림도 모두 성능이 저하된다.

• HTTP/2
  • HPACK : 압축
• HTTP/3
  • TCP를 없애고 QUIC과 UDP를 사용했다.
  • UDP : 포트 번호와 framing 하기 위해 사용한다.

• TCP 연결은 하나로 되어 있고, TCP 안에 스트림이 여러 개로 나뉘어 여러 일을 동시에 할 수 있다고 하지만, 각 segment들이 하나씩 전송되어야 함은 변함없다.
• 때문에 스트림 1의 segment가 손실되면 해당 segment를 재전송해 수신받기 전까지의 다른 segment들이 기다려야 하기 때문에 성능 저하가 발생한다.

QUIC

• TCP를 대체하기 위해 만들어졌다.

• QUIC은 UDP 기반으로 각각의 스트림이 독립적으로 작용한다.
• 하나의 스트림에 에러가 발생하더라도 다른 스트림에는 영향을 주지 않는다.

Reduced Signaling Latency

• 왼쪽 → 트랜스포트 계층의 TCP와 연결 요청/응답 하는 그림

• 오른쪽 → QUIC에 대해 요청과 응답을 하는 그림

• TCP의 경우 연결 요청을 하며 암호화를 위한 수학적 연산이 들어가는데, 이 연산이 굉장히 많은 시간적 부하를 준다.

• HTTP/1.1에서 8개의 TCP 연결을 썼을 때의 시간을 HTTP/2에서는 TCP를 1개만 사용함으로써 시간을 많이 줄였다.

• QUIC을 사용한 HTTP/3에서는 QUIC 연결과 동시에 트랜스포트 계층의 연결, 보안의 과정을 동시에 연결할 수 있도록 만들어 더 시간을 줄였다.

• QUIC은 연결 요청을 하면서 데이터를 전송한다.
• 이전에 이미 연결 설정을 해놓은 상태라면 인증 절차를 거치지 않고 이전의 연결을 사용함으로써 속도를 증가시켰다.

HTTP/3 is ‘HTTP over QUIC’

• HTTP/3는 HTTP/1.1, HTTP/2와 유사한 별도의 application이다.
• QUIC은 HTTP/3를 나르는 별도의 4계층 프로토콜이다.
• HTTP/3와 HTTP/2를 비교해보면 HTTP/2와 큰 차이점을 갖지는 않는다.
• 하지만 HTTP/2에서 사용한 스트림을 HTTP/3에서는 QUIC이 대신한다.

SIP

• SIP(Session Initiation Protocol)
• 미디어를 사용해 주고 받는 통신 프로토콜
• 서로가 연결을 하고 미디어를 주고 받는 단체
• ITF에서 만들어짐, 채팅, 화상 회의를 하는 멀티 미디어 세션을 만들고 연결 설정, 연결 해제를 한다.
• 채팅을 만드는 역할만 하고 미디어를 주고 받는 것은 다른 프로토콜을 한다.
• HTTP의 영향을 받았다. 0, 1의 비트 송수신이 아니라 human readable하게 만들어졌다.
• 줌, 구글 미트, 카카오 보이스

• 실시간으로 연결요청 하고 싶으면 SIP invite가 간다.
• 과거 유선 전화기에서부터 온 방식
• 들었을 때 소리가 나오는데 번호가 나오면 상대방과 연결 설정을 한다.
• 누군가 전화 프로그램을 끄면 SIP BYE가 가서 연결을 끊는다.
• 서버에 로미오, 줄리엣이 통신을 했다는 기록이 남는다.
• MSRP : 임시 방. 여러 사용자가 공유하는 세션방. 구독된 사람에게 전달하는 방식
• SIP는 오래된 프로토콜이다.

• 구체적인 단계를 구분하는 방식으로 차별화 가능
• Delivered, Displayed → 다음과 같은 방식으로 카카오톡 채팅을 읽었는지를 확인 가능

Advanced Web Technologies

WebRTC

• WebRTC(Web Real-Time Communication) : 무료, 오픈소스 프로젝트이다.

• 구글에서 만든 기술.

• 웹 기반으로 실시간 통신을 할 수 있는 오픈소스 프로젝트

• SIP는 서버가 있지만 WebRTC는 서버가 없고 직접적인 P2P 통신을 만들었다.

• 웹브라우저에 들어가 있는 기본 화상회의 기능이다.

• 웹브라우저 안에 화상회의, 전화, 채팅을 위한 모든 기술이 들어가 있다.

• P2P 이상과 현실

• 이상적으로는 서버가 없다. 하지만 이는 공유기를 공유하는 가까운 경우에 해당하고, 멀리 있다면 서버가 필요하다.

• STUN 서버

• A, B는 각자 유무선 공유기가 부여한 Private IP 주소를 가지고 있지만 외부에 있는 서버와 통신하려면 NAT, PAT를 통과한 Public IP 주소를 알아야 한다. 이렇게, Public IP 주소를 제공하는 역할을 STUN 서버가 담당한다.

• Public IP 주소를 제공해야 하기 때문에 STUN 서버는 인터넷 쪽에 위치한다.

• Signaling 서버

• 1대1 통신의 경우 서버 없이 P2P로 주고 받을 수 있지만, 여러 명이 통신하려면 연결 요청이 필요한데 Signaling 서버가 이 역할을 한다.

• 멀리 떨어져 있는 기기 사이 연결 요청 및 해제를 한다.

• Signaling 서버는 데이터를 주고 받지는 않는다. 연결 설정만 한다.

• Stun, Signaling 서버가 구글 미트에서 담당하는 역할이다.

• 즉, P2P 서버는 Turn 서버를 통해서 주고 받는다. 트래픽은 이 서버를 통해 전달된다. 세션 방이 많아짐에 따라 발생하는 트래픽을 위해 서버를 사용한다.

• 구글 미트, 줌 채팅방안에 들어갈 수 있는 인원이 제한되는 이유

  • 인원이 적으면 P2P를 통해서 주고 받는다.
  • 인원이 많아지면 비용을 지불해야 하는데, 여러명에게 전송하려면 브라우저의 전송 한계로 인해 전송하기 힘들어진다.
  • 때문에 서버를 사용해야 하고, 서버 사용 비용이 발생한다.
  • transcoding → 서버를 통해 진행한다?
  • 화상회의를 마치고 나면 영상을 기록할 수 있는데 서버에 영상을 저장하는 것이 가장 좋은 품질을 갖는다.

WebVR/WebXR

• 메타버스
• AR은 전망이 있을 듯
• 웹 브라우저로 VR, AR을 만들고 실어 나르는 기술
• Mozilla foundation에서 제작한 Mixed Reality 기술

asm.js

• 웹 브라우저에 대한 C/C++
• 어셈블리어를 js와 합쳤으나 망했다.

웹 어셈블리

• 기계어로 번역
• 모든 언어를 이해할 수 있는 웹 어셈블리를 만들어 적용되는 코드를 짜서 넣으면 된다.
• 웹 어셈블리 위에서 돌아가는 바이너리로 만들어주고, 읽어서 실행하면 실행된다.
• 웹브라우저, 서버 둘 다 돌아갈 수 있도록 했다.

WebGPU

• 브라우저가 GPU를 건드릴 수 있도록 한다.
• 보안보다 더 중요한 것은 성능이 아닐까?
• 브라우저가 GPU, 하드웨어 자원을 직접 접근한다.
• 벤치마크를 측정했을 때 WebGPU 성능이 매우 좋다.

Solid

• Web3.0 - blockchain
• Solid(Social linked data)
• 내 정보에 대해 내가 공개 유무를 결정하고 회사는 내 정보가 있는 위치, 메타 정보를 가져가서 설정하는 아이디어.