Sockets

Application Layer에서 프로세스는 socket을 통해 message를 주고 받음
Sockets은 OS에서 제공해주는 API 중 하나
다른 컴퓨터의 위치를 지정할 땐 IP + Socket PortNumber를 사용
IP는 인터넷상에 존재하는 컴퓨터를 찾기 위한 것이고, 그 컴퓨터 안의 프로세스를 찾기 위한 것이 port

Type Of Sockets

소켓은 TCP(SOCK_STREAM)와 UDP(SOCK_DGRAM) 두가지 타입

• Server: bind()를 통해 특정 포트번호와 연결, accept()까지 진행 후 client의 요청이 올 때까지 대기
• Client: 포트를 특정할 필요가 없기 때문에 bind()가 없음

데이터를 보낼 때 요구되는 것

Application layer 는 Transport layer에 종속적이며, Transport layer에서 Application layer에 다음과 같은 것들 보장받길 원함
TCP를 사용할 경우 1번은 보장함(reliable). 따라서 나머지 요소들을 Application에서 알아서 처리❗️

• Data integrity(내구성) : 어플리케이션은 100% 손실이 없는 데이터를 요구하거나, loss에 견딜수 있어야한다.
• Timing : 어떤 어플리케이션은 효율성을 위해 적은 딜레이를 요구한다. 제한시간
• Throughput : 어떤 어플리케이션은 효율을 위해 최소한의 throughput이 요구된다. 처리량
• Security : 보안이 요구된다.

DNS

• Domain Name System으로 hostname을 ip 주소로 해석하는 프로토콜
• HTTP 통신을 하기 위한 준비 과정
• DNS는 UDP 기반 / HTTP는 TCP 기반
• IP, Port 번호를 일일이 다 기억하기 힘드니, Domain Name으로 접속할 수 있도록 한 시스템 - 일종의 전화번호부
• 한 곳에 몰아 놓으면 문제가 생기기 때문에 계층화(hierarchial database)하여 구성
  • 트래픽 집중
  • 먼 거리에 위치한 국가의 데이터베이스 접근 불리
  • 유지보수
  • 에러를 대비한 클러스터링 없음

DNS 기본 동작원리

• 1단계. 사용자 시스템은 DNS 애플리케이션의 클라이언트 측을 실행한다.
• 2단계. 브라우저는 URL에서 호스트 이름 example.com를 추출하고 호스트 이름을 DNS 애플리케이션의 클라이언트 측에 전달한다.
• 3단계. DNS 클라이언트는 호스트 이름이 포함 된 쿼리를 DNS 서버로 보낸다.
• 4단계. DNS 클라이언트는 DNS 서버로부터 호스트 이름에 대한 IP 주소(93.184.216.34)가 포함 된 응답을 받는다.
• 5단계. 브라우저가 DNS에서 IP 주소를 받으면 해당 IP 주소의 포트 80에있는 HTTP 서버 프로세스에 대한 TCP 연결을 시작할 수 있다.

DNS 계층구조

DNS의 특징은 분산 계층 데이터베이스이다. DNS를 많은 서버로 나누고 이들을 계층 형태로 구성하며 전 세계로 분산되어 있다.
도메인 주소 맨 뒤에는 사실 .이 생략되어 있다. 만약 URL이 blog.example.com이라면 사실은 blog.example.com.이라는 도메인이 있는 셈이다. 그리고 이에 해당하는 IP를 찾아가는 과정을 설명하자면 아래와 같다.

• 1단계. .에 해당하는 Root DNS 서버 중 하나에 먼저 접속한다. 그리고 그 서버에서 최상위 레벨 도메인이 .com을 갖는 Top-level DNS 서버 IP 주소를 찾는다.
• 2단계. 다시 Top-level DNS 서버에 접속합니다. 다시 그 서버에서 .example.com을 갖는 책임서버(Second-level) DNS IP 주소를 찾는다.
• 3단계. .example.com을 갖는 책임서버에 접속한다. 거기서 마침내 blog.example.com 도메인에 해당하는 IP를 찾을 수 있게 되는 것.

HTTP (Hypertext Transfer Protocol)

• 웹 애플리케이션 프로토콜
• Stateless: 과거의 클라이언트의 요청에 대한 정보, 상태를 저장하지 않는다. 필요시 cookie 사용
• Pull 방식 (Request 보내면 Response 받는 형식. SMTP는 push형식)
• 원래는 TCP 기반이었으나, 현재는 더 발전된 형태 사용 - HTTP/1.x는 TCP 사용 → HTTP/3.0은 UDP 채택
• Default port번호 80 사용
• 단방향 통신
• safari, explorer, chrome 등 브라우저 모두 다른 application이지만 동일한 프로토콜 채용으로 통신 가능

HTTP 연결의 두 가지 방식

• Non-Persistent

  • 지속적이지 않은 HTTP, TCP 커넥션을 HTTP 사용후 close
  • 필요할 때에 TCP연결을 한다. 매 http 마다 TCP 커넥션을 새로 맺음
  • 오브젝트마다 2번의 RTT+전송타임이 걸린다고 볼 수 있음. 더 긴 응답시간
    • Round Trip Time(= 패킷 왕복 시간)

• Persistent

  • 한번 TCP연결을 하고 종료 될 때까지 재사용 한다.
  • 여러번의 오브젝트를 보낼 수 있다.
  • 클라이언트/서버 간 하나의 TCP 커넥션으로 여러개의 HTTP 송수신을 수행
  • 평균적으로는 1번의 RTT+전송타임이 걸린다고 볼 수 있음.
  • HTTP 1.1 버전에서 default. (지속커넥션 사용), 파이프라인 사용

HTTP 1.0

• 장점
  • 각각의 객체마다 하나의 TCP connection을 사용하기 때문에 속도는 빠르다 (대기 시간이 없기 때문)
• 단점
  • 각각의 객체마다 TCP connection을 사용하게 되면 socket을 해당 수 만큼 생성한다. 이는 메모리의 사용률을 높이게 되고 리소스를 많이 잡아먹게 된다.

HTTP 1.1

• 추가적으로 요청할 객체를 예상하고 지정한 timeout동안(= Keep alive하다면) 소켓 연결을 끊지 않고 바로 다시 요청을 한다.
• 기존 연결에 대해서 handshake 생략
• 병렬적으로 객체를 요청하여 파이프라이닝 형태로 응답을 기다리지 않고 데이터를 계속 보내는 방식 사용.
  • 이전 요청에 대한 응답이 완전히 전송되기 전에 다음 전송을 가능헤 하여, 커뮤니케이션 레이턴시를 낮춤
• Window Size 제한은 있으며, 많은 대기시간을 줄일 수 있다.

한계 - 만약 그렇다면 각각 다른 두 요청을 처리한다고 한다면?

• HTTP의 HOL Blocking (Head of line Blocking): 첫 번째 요청이 오래걸려 다른 모든 요청이 차단되어 기다려야하는 경우. 비효율적인 상황 발생
• TCP 연결을 병렬적으로 이용하는 방식을 사용하여 보완: 여러 개의 연결을 만들어 사용할 경우, 추가 메모리와 CPU 리소스 낭비라는 단점이 존재하였고
• 그래서 2.0이 등장

HTTP 2.0(2015) - 멀티플렉싱(응답다중화)

• 1.1에 비하여 전송효율, 보안기능, 헤더 압축 등 기능이 포함된 차세대 HTTP 프로토콜
• 서버, 클라이언트 HTTP/2.0을 모두 지원해야 사용가능하며, 하나라도 미지원한다면 HTTP 1.1로 동작
• 1개의 메시지 블록으로 구성된 요청, HOL Blocking을 유발하는 것을 방지하기 위해
• 작은 스트림으로 분리하여 전송, 바이너리 인코딩을 통해 최적화 - 관련 flag를 통해 전송 후에는 다시 decode
• 여러 개의 스트림을 인터리빙: 스트림을 서로 끼워 맞춰어 구성
  • 여러 개의 연결이 없어도 되기 때문에 리소스 비용도 절감
  • 이로써 응답 다중화가 가능

한계 - 어플리케이션 계층의 메시지 문제는 해결하였다 하더라도 전송계층의 TCP방식에서 HOL Block문제

• TCP는 Reliable에 원칙에 따른 신뢰성 보장이 기본
  • 패킷이라도 빠지거나 없어지면 다시 전송이 이루어지고
  • 목적이 달성되기 전까지 전체 TCP연결이 중단됨
• 따라서 UDP 기반의 3.0이 등장

HTTP 3.0(2018)

👉🏻 HTTP/3와 QUIC 알아보기

• 이례적으로 기반 프로토콜을 UDP를 기반으로 하는 QUIC를 사용
• UDP를 사용하지만 그렇다고 기존의 신뢰성 있는 통신이라는 타이틀을 포기한 것은 아니다.
• 스트림 연결과 암호화 스펙 등을 포함한 모든 핸드쉐이크가 단일 요청/응답으로 끝난다
  • 0-RTT, 1-RTT 핸드쉐이크를 둘다 제공 하기 때문에 기존의 3-way handshake로 발생되는 시간을 줄여줌
• QUIC는 프로토콜 내에 TLS를 포함하여 데이터 전달과 암호화 절차가 동시에 수행된다.
  • TCP는 연결을 시작(초기화)할 때 3 Way Handshake를 연결을 종료할 때 4 Way Handshake 과정을 거친다.
  • TLS+TCP는 세션키를 주고 받고 암호화된 연결을 성립한 후에 세션키와 함께 데이터를 교환한다.
• Source Address와 무관하게 서버에 대한 연결을 고유하게 식별하는 연결 식별자가 포함되어 있어, IP주소가 변경되더라도 커넥션을 유지할 수 있다 - 스트림 중 하나에서 어떤 패킷이 손실되더라도 해당 스트림만 멈추게 됨

정리 - 전송계층의 TCP방식에서 UDP 방식으로 전환하면서 HOL Block문제, 핸드세이크로 인한 지연 문제 해결

• 멀티미디어 위주의 스트리밍과 사이트 고도화에 대한 지연에 있어서도, 구글의 경우 로딩 시간 평균 3% 개선, 유튜브 시청 중 버퍼링 평균 30% 개선

Web caches(proxy server)

• 웹 캐시는 클라이언트 입장에선 서버역할을하며, 서버입장에서는 클라이언트 역할을 한다
• origin server에 HTTP 요청을 하는 대신 proxy 서버에 HTTP 요청
• 서버와 클라이언트 사이에 중계기로서 대리로 통신을 수행하는 것을 가리켜 '프록시', 그 중계 기능을 하는 것을 프록시 서버라고 함
• 프록시 서버 중 일부는 프록시 서버에 요청된 내용들을 캐시를 이용하여 저장함
• 이렇게 캐시를 해 두고 난 후에, 캐시 안에 있는 정보를 요구하는 요청에 대해서는 원격 서버에 접속하여 데이터를 가져올 필요가 없게 됨
• 전송 시간과 비용을 절약 + 불필요하게 외부와의 연결을 하지 않아도 되기 때문에 네트워크 병목 현상을 방지하는 효과
  • 응답시간을 줄일 수 있다. (일반적으로 프록시 서버가 오리진 서버보다 클라이언트에 훨씬 가까움)
  • 엑세스 링크에 트래픽을 줄일 수 있다.

Conditional GET - 일관성 문제

• Cache에 저장된 데이터가 최신이 아닐 수 있기에 브라우저로 전달되는 객체들이 최신임을 확인하며 캐싱할 수 있도록 Conditional GET 사용
• HTTP 요청에 If-Modified-Since 헤더 라인이 포함되어, 서버에 있는 객체의 마지막 수정된 날짜와 비교.
  • 수정된 객체라면 객체를 보내줌 (200 OK + data)
  • 최신 상태이면 object를 보내지 않음 (304 Not modified)

HTTP Cookies

keeping "state"

• 세션 관리(Session management)
  • 서버에 저장해야 할 로그인, 장바구니, 게임 스코어 등의 정보 관리
• 개인화(Personalization)
  • 사용자 선호, 테마 등의 세팅
• 트래킹(Tracking)
  • 사용자 행동을 기록하고 분석하는 용도

단방향적이고 statelsss인 HTTP에 필요에 따른 상태 관리가 가능하도록 별도의 저장을 통한 데이터 활용
모든 요청 / 응답의 헤더에 쿠키를 설정하여 함께 전송, 웹 사이트의 백엔드 데이터베이스에서 이를 비교
쿠키 파일은 사용자의 브라우저에 의해 관리되고 사용자의 호스트에 보관
쿠키는 한개에 4KB 까지 저장 가능하며, 최대 300개 까지 저장할 수 있는 텍스트 파일 - 이름, 값, 만료날짜, 경로 정보

캐시와 쿠키의 차이

쿠키

• 정보를 사용자의 PC 임시 저장소에 저장
• 사용자가 임의로 저장
• 사용자와 관련된 정보 저장
• 비밀번호, 방문 날짜 등

캐시

• 정보를 웹 서버의 저장소에 저장
• 사용자의 의지와 관계 없이 무조건 자동 저장
  • ex) 웹 사이트에서 영상 처음 보면 오래걸리는데, 다시 보면 빨리 로딩됨