최근의 transport layer는 서비스 위주의 프로토콜입니다. HTTP는 Transport 상위 layer에 있으며, web-service & browser를 담당합니다. SIP는 카카오톡과 같은 instance message를 다룹니다.

HTTP 1.x

Web client and Server

• Web browser -> client가 된다. client-server간 http를 사용하여 통신합니다. http를 통해 정보를 요청/제공 받는다.

Resources

Files들을 의미합니다

Static content

: HTTP request이전에 존재하였으며, 요청 받아도 내용이 바뀌지 않는 파일입니다. 내가 Netflix, youtube에서 보는 영화는 static contents입니다. 이러한 불변성의 이유로 static이라고 명칭합니다

Dynamic content

: HTTP request 이후에 생기는 파일들입니다. 사용자의 요청에 의해서 파일들이 만들어지며, program에 의해 생성됩니다. 예를 들어 은행 거래의 잔고 요청의 경우, 요청을 받을시에 data를 계산하여 파일을 만듭니다. 이외에 Live images 등이 있습니다.

Media Types

: E-Mail의 일종이라 볼 수 있습니다. E-mail내의 contents type과 length를 표현하며, bit가 아닌 사람이 이해할 수 있도록 자연어로 메시지가 되어 있습니다. 이는 통신 기술의 발전으로 가능해졌습니다.

URI

: Resource을 표현하기 위한 식별자입니다. 목적은 인터넷 상에서 resource를 찾아가는 것이며, unique하며, 위치에 대한 정보를 가집니다. URL과 URN이 있으며, URL의 경우 찾아갈 컴퓨터의 주소와 그 컴퓨터내의 파일 위치가 있습니다. URN은 큰 의미가 없습니다.

Transactions

HTTP Messages

: Request와 Response로 이뤄진다. Request 메시지는 text-based이며, 파일을 달라는 'GET'명령어, 프로토콜 정보, computer 이름이 있습니다. Response도 text-based이며, 'GET'에 대한 응답값과 content 타입과 길이 정보가 있습니다.

HTTP Method

• Get : client가 서버로부터 받기를 원하는 리소스를 요청하는 것. 서버가 client에게 파일을 준다. Download File (browser 입장)
• Put : client가 서버에 저장할 리소스를 주는 것이다. Upload File. (browser 입장)
• DELETE : 서버에 있는, URL에 의해 요청받은 리소스를 삭제하는 것이다.
• POST : 함수 입력 parameter를 전달하듯이, Client가 입력 데이터를 서버에게 전달시 사용한다.
• HEAD : Get과 유사하다. 다만 Response에서 Get과 달리 파일 본체는 보내지 않고, 파일과 관련된 정보만 보낸다.
• Trace : 프록시가 있는지 없는지 확인하는 정도의 메시지이다. 메시지에서 'Via'가 있는 경우 프록시가 있는 것을 알 수 있다. Debug 목적에서 훌륭한 도구이다.
• Options : 사용하는 options들을 다 알려달라는 뜻이다. 대부분의 사이트들은 보안상의 이슈로 거절한다.

Status code

: http response는 상태 코드값을 가지고 있다. 3자리 수로 되어있으며, 200은 okay, 302(Redirect)는 정보가 있는 다른 서버로 옮겨서 가져오라는 뜻이며, 404는 파일이 없다는 뜻이다.

Messages

• Request/Response 메시지 속에는 다양한 정보들을 포함시킬 수 있습니다.
• HTTP가 프로그래밍 언어 안에 들어간 이유로는 HTTP 자체가 중요해졌기 때문에 이떤 언어든 지원을 해야 하지만, 그것을 가지고 programming을 하여 client-server간의 동작이 다양해질 수 있다는 것을 간접적으로 표현한 것입니다.
• HTTP가 TCP/IP를 권장하는 이유로는 신뢰성 때문입니다. UDP를 사용할 경우 정보의 유실이 발생할 수 있고, Http는 유실을 바라지 않았으므로 TCP를 사용했습니다. 하지만 이로인해 TCP가 가지고 있는 성능 저하등의 문제를 그대로 가지고 있기도 합니다.
• HTTP connection process : URL을 입력하면 먼저 host이름을 get하고, DNS를 통해 text로 되어있는 hostname을 IP address로 변환합니다. 이후에 서버의 well known 포트 번호를 얻어 연결 설정 이후, request-response를 반복한 이후, connection을 해제하는 과정이 있습니다.

HTTP Proxy 서버

• HTTP client와 서버 사이에 존재하지만 보이지 않는다.
• Client와 서버간의 트래픽을 쳐다보면서, 일부 client의 요청을 block한다(보안적인 측면). 또한 바이러스나 불손한 것들을 막아줄 수 있다.(firewall). 예를 들어서 여러 client를 이용한 디도스 공격의 경우, proxy에서 차단할 수 있습니다.
• 성능 최적화 측면에서는 만약 출장 간 나라의 네트워크가 안좋은 경우, proxy가 압축을 하여 content를 보낼 수 있으며, 가장 흔한 성능 최적화는 client가 서버쪽으로 요청하는데, proxy가 이를 가지고 있다가 직접 response를 주는 cache기능이다.

Web Server Development

: Request/Response가 모두 가능한 프로그램들이다. 메시지를 주고 받는 것은 HTTP로, 서버에서 해야할 일(logic 구현)은 built-in으로 되어있는 프로그래밍 언어의 라이브러리 사용이 가능하다. C/C++은 언어 안에 없기 때문에, 따로 구해 써야하고(프록시젠) 난도가 높다.

Web based Mobile Application

: Web 기술의 확장을 통해 모바일 앱을 만들 수 있다.

HTTP 2.0

: 구글이 초안과 표준을 오픈소스로 뿌렸다. 기존 HTTP 1.x에서 발생한 문제들을 개선하는 방향으로 진화하였다. 닉네임은 speedy이다.

• 텍스트가 아닌 binary 프레임(0과 1의 조합)으로 구성하여 메시지 사이즈를 줄였다.
• 기존 1.0은 여러개의 request를 순서대로 받고 순서대로 response하지만, 2.0은 각각의 요청에 대해 독립적으로 response하여 다중 요청을 동시에 처리 가능하다.(Multiplexing)
• 반복적으로 사용되던 헤더를 index로 표시하여 크기를 줄임으로써, 네트워크 부하를 줄일 수 있다.(Header Compression)
• 사용자가 요청하지 않는 한 응답을 하지 않던 1.0과 달리, 사용자 요청 없이도 서버가 미리 Content를 전송할 수 있다.(Server Push) 광고를 수익으로 하는 구글은 이를 통해, 광고를 사용자 요청 없이도 보낼 수 있었다.

HTTP 3.0

QUIC

UDP에 올라간 HTTP이다. Web-service를 잘하기 위해서 고안되었다. TCP를 사용하면서 발생한 성능저하 문제를 해결하고자 하였다. 연결 설정 때 오랜 시간이 걸린다는 문제(초기접속 시간), Congestion control로 인한 delay(전송 시간), 대역폭 조절에 대해서 개선하고자 하였다.

또한 OS 커널내에서 구현하는 것을 피하려 하고, User Space에서 동작하도록 한다.

• Fast Estabilshment : 연결 설정에서 걸리는 오버헤드를 줄이고자 하였다. 기존 TCP + TLS는 연결 과정이 많고 복잡한 것과 달리, QUIC은 Simple한 연결 설정 과정을 가진다. 만약 한 번 연결 설정을 한 기록이 있으면, 추가 작업이 필요없다. 이를 통해 많은 시간의 절약이 되었다.
• 강화된 에러 복구 : 에러 검출 및 복구 기능이 없는 UDP를 베이스로 사용하지만, multiplexing 개념에 따라 각각의 request에 대한 에러 검출 및 복구를 진행한다.
• Application 공간에서의 실행에 따른 context switching에 의해 일부 성능저하가 있으나, 개발자의 자유도가 증가한다는 장점과 최근의 컴퓨터들은 overhead에 큰 영향을 받지 않는다는 점과 상쇄한다.

Client, Server Deployment

: Chrome에 default로 quic이 들어가있으며, 서버에서는 go언어로 quic을 구현하였다. 구글은 브라우저와 서버를 가지고 있어서, 표준에 얽매이지 않게 되며, 이것이 chrome/Android OS를 개발하는 이유이다.

SIP

주로 instant 메신저 프로그램(카카오톡 등)들에 사용되며, 실시간으로 미디어 전송이 가능하다. 여러명의 참여자가 있는 미디어 세션을 생성,수정,제거를 하기 위해 고안되었다. 메시지를 HTTP처럼 text-based로 사용한다.

SDP는 IP address, Port번호, 코덱등의 정보를 포함한다. SIP가 주고 받아야 하는 정보를 가지고 있으며, 실어나르는 것이 SIP, 실어 나름을 당하는 것이 SDP이다.

User Agent

: HTTP와 같이 User agent Client와 서버가 있다.

Registrar

: 사용자의 네트워크 주소는 바뀌나 ID는 동일하므로, SIP의 아이디를 IP address로 매핑하는 역할을 한다.

Proxy server

: SIP Router로써, SIP 메시지들을 user agent나 다른 프록시 서버에게 받는다.

Redirect Server

: SIP 주소를 새로운 주소로 변환해 준다.

Advanced Web technologies

WebRTC

: 웹브라우져 자체가 강력해지고, 그 위에서의 언어들이 강력해지면서, 운영체제까지 내려가서 실행할 필요가 줄어들었다. WebRTC는 RTC를 위한 API이며, 직접적인 peer-to-peer 통신을 하므로, 서버가 필요없으며, 오디오,비디오 통신이 가능하다.

Web-assembly

기존의 C++로 만들어서 컴퓨터에서 실행하는 고속 성능이 필요한 프로그램들을, 웹브라우저 위에서 올려서 실행을 가능하도록 하는 것에 초점을 둡니다.

Solid

: permission없이 데이터를 가져가는 것을 막고자 하였으며, 데이터의 링크만 가져갈 수 있도록 한 것이다.