[CS/ Network] 컴퓨터 네트워킹 하향식 접근 8판 2장 애플리케이션 계층

yujeongkwon·2023년 7월 18일

CS / Network

목록 보기

3/27

2.1 네트워크 애플리케이션의 원리 74
2.1.1 네트워크 애플리케이션 구조 75
2.1.2 프로세스 간 통신 77
2.1.3 애플리케이션이 이용 가능한 트랜스포트 서비스 80
2.1.4 인터넷 전송 프로토콜이 제공하는 서비스 82
2.1.5 애플리케이션 계층 프로토콜 85
2.1.6 이 책에서 다루는 네트워크 애플리케이션 86
2.2 웹과 HTTP 86
2.2.1 HTTP 개요 87
2.2.2 비자속연결과자속연결 89
2.2.3 HTTP 메시지포맷 92
2.2.4 사용자와 서버간의 상호작용:쿠키 96
2.2.5 웹캐싱 98
2.2.6 HTTP/2 103
2.3 인터넷전자메일 106
2.3.1 SMTP 107
2.3.2 메일메시지포맷 110
2.3.3 메일접속 프로토콜 111

🔎 2.1 네트워크 애플리케이션의 원리

네트워크 애플리케이션 개발의 중심 : 다른 위치의 종단 시스템에서 동작하고 네트워크를 통해 서로 통신하는 프로그램을 작성하는 것
- ex) 웹 애플리케이션
  클라이언트 : 사용자의 호스트(데스크톱，랩톱，태블릿，스마트폰 등)에서 실행되는 브라우저 프로그램
  서버 : 서버 호스트에서 실행되는 웹 서버 프로그램
- ex) 온디맨드 비디오(넷플릭스) 애플리케이션
  클라이언트 : 사용자의 스마트폰, 태블릿，컴퓨터상에서 실행되는 넷플릭스 제공 프로그램
  서버 : 넷플릭스 서버 호스트에서 실행되는 넷플릭스 서버 프로그램

웹/앱개발자는 이렇게 여러 종단 시스템에서 실행되는 소프트웨어(c or java언어)를 작성
근데 우리가 네트워크 코어 장비에서 실행되는 소프트웨어(라우터, 링크계층 스위치)까지 작성하냐!?!? NONO~ 하고 싶어도 못해
-> 각 계층 장비는 해당 계층에서만 기능
= 네트워크 애플리케이션을 위한 통신은 종단 시스템 간의 애플리케이션 계층에서 발생

🔧 2.1.1 네트워크 애플리케이션구조

애플리케이션 구조 != 네트워크 구조

애플리케이션 구조
- 애플이케이션 개발자가 설계
- 애플리케이션이 다양한 종단 시스템에서 어떻게 조직되어야 하는지를 알려줌.
- 주로 잘 알려진 구조인 클라이언트-서버 구조 or p2p 구조 중 하나로 작성됨.
클라이언트-서버 구조
- Server : 항상 동작하고 있는 호스트 -> 클라이언트는 서버로 언제든지 패킷전송, 연결 가능
- client : 서버의 서비스 요청, 가끔 또는 항상 켜져 있을 수 있음.
- 클라이언트등 끼리는 서로 직접적으로 통신하지 않음
- 서버가 고정 IP 주소라는 잘 알려진 주소를 가짐.
- ex) 웹，파일 전송, 원격 로그인，전자메일
데이터 센터（data center)
- 많은 수의 호스트를 갖춘 한 가상의 서버를 생성하는 역할로 사용
- 존재 이유 : 하나의 서버로만 요청을 처리한다면 이에 맞춰 서버가 신속하고 제대로 작동x
- ex) 검색 엔진（예: 구글)，소셜 미디어 네트워킹（예: 페이스북，인스타그램）등
- 보통 하나의 데이터 센터는 10만 개 정도의 서버를 갖춤
- 서비스 제공자는 데이터 센터로부터 데이터 전송을 위해 상호연결과 대역폭에 합당한 비용 지불
P2P 구조
- 항상 켜져 있는 인프라스트럭처 서버에 거의 의존x
- 애플리케이션은 peer라는 간헐적으로 연결된 호스트 쌍이 서로 직접 통신
- peer
  - 서비스 제공자가 소유x
- 사용자들의 데스크톱과 랩톱으로 대부분 가정，대학，사무실에 위치
- 특정 서버를 통하지 않고 피어가 통신 => 피어 투 피어（peer-to-peer)라고 함.
- ex) 파일 공유 애플리케이션인 비트토렌트（BitTorrent）
장점
- 자가 확장성（self-scalability）
  - 각 피어들은 파일을 다른 피어들에게 분배 -> 시스템에 서비스 능력을 추가
- 비용 효율적
  - 일반적으로 상당한 서버 인프라스트럭처와 서버 대역폭을 요구X
단점
- 고도의 분산 구조 특성 -> 보안，성능，신뢰성 면에서 큰 문제

난 tcp 처럼 신뢰성있는 연결 살짝 논리적인 개념같이 생각했는데 ㄹㅇ 물리적 연결이였음. 무션 연결로 이케이케 통신하는거래 각각이 그래서 줠라느린게 문제 -> 그래서 잘 안씀

📳 2.1.2 프로세스 간 통신

실제 통신하는 것 : ~~프로그램~~ 프로세스（process）
프로세스: 종단 시스템에서 실행되는 프로그램
통신 프로세스가 같은 종단 시스템에서 실행될 때 그들은 서로 프로세스 간에 통신
종단 시스템의 운영체제에 의해 좌우된다.
2개의 종단 시스템에서 프로세스는 컴퓨터 네트워크를 통한 메시지（message） 교환으로 통신
- 송신 프로세스는 메시지를 만들어서 네트워크로 전송
- 수신 프로세스는 메시지를 받고 역으로 메시지를 보냄으로써 응답
클라이언트와 서버 프로세스
- 클라이언트 : 두 프로세스 간의 통신 세션에서 통신을 초기화(다른 프로세스와 세션을 시작하려고 접속을 초기화)하는 프로세스
- 서버 : 세션을 시작하기 위해 접속을 기다리는 프로세스
- ex) 웹 : 클라이언트 프로세스 - 브라우저,서버 프로세스 - 웹 서버
- ex) P2P 파일 공유 : 클라이언트 프로세스 - 파일을 내려받는 피어,서버 프로세스 - 파일을 올리는 피어
  - 한 프로세스가 클라이언트와 서버 둘다 가능
프로세스와 컴퓨터 네트워크 사이의 인터페이스 : 소켓
- 소켓(socket) : 호스트의 애플리케이션 계층과 트랜스포트 계층 간의 인터페이스
- = 네트워크 애플리케이션이 인터넷에 만든 프로그래밍 인터페이스 -> 애플리케이션과 네트워크 사이의 API(Application Programming Interface)라고도 함
- 애플리케이션 개발자는 소켓의 애플리케이션 계층에 대한 모든 통제권을 가짐
- but 소켓의 트랜스포트 계층에 대한 통제권 X
  - (1) 트랜스포트 프로토콜의 선택
  - (2) 최대 버퍼와 최대 세그먼트 크기
  - 등 약간의 트랜스포트 계층 매개변수의 설정만 가능
프로세스 주소 배정
- 수신 프로세스를 식별하기 위해 필요한 두 가지 정보
  (1)호스트의 주소
  - 인터넷에서 호스트는 IP 주소로 식별
  * IP 주소 : 32비트로 구성, 호스트를 유일하게 식별
  (2) 그 목적지 호스트 내의 수신 프로세스를 명시하는 식별자
  - 목적지 포트 번호(port number) : 일반적으로 한 호스트가 많은 네트워크 애플리케이션을 수행하기에 이를 식별
  - 인기 있는 애플리케이션은 특정한 포트 번호가 할당
  ex) 웹 서버는 포트 번호 80번, 메일 서버는 포트 번호 25번
🧵 2.1.3 애플리케이션이 이용 가능한 트랜스포트 서비스
송신 측의 애플리케이션은 그 소켓을 통해 메시지 전송 -> 그 소켓의 반대편에서 트랜스포트 프로토콜은 메시지를 수신 프로세스의 소켓으로 이동!
네트워크는 하나 이상의 트랜스포트 프로토콜 가짐, 웹/앱 개발자는 트랜스포트 프로토콜 중 1택
트랜스포트 계층 프로토콜 제공 서비스 : 신뢰적 데이터 전송，처리율，시간, 보안
⭐신뢰적 데이터 전송
- 패킷들은 컴퓨터 네트워크 내에서 손실될 수 있음.
  - ex) 패킷이 라우터의 버퍼에서 오버플로（overflow）
  - ex) 패킷의 비트가 잘못되면 호스트 혹은 라우터에 의해 버려질 수 있음.
- 신뢰적 데이터 전송 : 데이터가 올바르고 완전히 다른 애플리케이션에 전달되도록 보장
  - 트랜스포트 프로토콜은 송신 프로세스는 데이터를 소켓으로 보내고 데이터가 오류 없이 수신 프로세스에 도착 확신
  - ex) 전자메일，파일 전송，원격 호스트 접속，웹 문서 전송, 재무 에플리케이션
- +) 손실 허용 애플리케이션 : 어느 정도의 데이터 손실 감수
  - ex) 실시간 오디오/비디오 혹은 저장 오디오/비디오 같은 멀티미디어 애플리케이션
처리율
- 처리율 : 네트워크 경로를 따라 송신 프로세스가 수신 프로세스로 비트를 전달할 수 있는 비율
- 처리율은 시간에 따라 변동
  - 다른 세션들이 네트워크 경로를 따라 대역폭을 공유하고，이 세션들이 생겼다 없어졌다해서
- 대역폭 민감 애플리케이션 : 처리율 요구사항을 갖는 애플리케이션
  - 트랜스포트 프로토콜은 어느 명시된 속도에서 보장된 가용 처리율을 제공
- +) 탄력적 애플리케이션 : 가용한 처리율을 많으면 많은 대로 적으면 적은대로 이용
  - ex) 전자메일，파일 전송，웹 전송이 융통성 있는 애플리케이션
시간
- 트랜스포트 계층 프로토콜은 시간 보장(timing guarantee)을 제공
- 실시간 상호작용 애플리케이션에서 사용
- ex) 인터넷 전화，가상 환경，원격회의, 다자간 게임
보안
- 트랜스포트 프로토콜은 애플리케이션에 하나 이상의 보안 서비스를 제공
  - 송신 호스트에서 트랜스포트 프로토콜 : 송신 프로세스가 전송하는 모든 데이터를 암호화
  - 수신 호스트에서 트랜스포트 프로토콜 : 수신 프로세스로 전달하기 전에 데이터의 암호를 해독
  - 기밀성, 무결성, 종단 인증 제공

📫 2.1.4 인터넷 전송 프로토콜이 제공하는 서비스

TCP 서비스
- TCP 서비스 모델은 연결지향형 서비스와 신뢰적인 데이터 전송 서비스를 포함
- 연결지향형 서비스
  1. 핸드셰이킹 과정 : 애플리케이션 계층 메시지를 전송하기 전, TCP는 클라이언트와 서버가 서로 전송 제어 정보를 교환
    - 이 클라이언트와 서버에 패킷이 곧 도달할 테니 준비하라고 알려주는 역할을 한다.
  2. TCP 연결이 두 프로세스의 소켓 사이에 존재
    - 전이중연결 : 두 프로세스가 서로에게 동시에 메시지 전송 가능
  3. 애플리케이션이 메시지 전송을 마치면 연결을 끊어야 한다.
- 신뢰적인 데이터 전송 서비스
  - 1. 송신측이 바이트 스트림을소켓으로 전달
  - 1. 바이트 스트림이 손실, 중복되지 않게 수신 소켓으로 전달
- 혼잡 제어 : 통신하는 프로세스의 직접 이득보다는 인터넷의 전체 성능 향상을 위한 서비스
  - 네트워크가 혼잡 상태에 이르면 프로세스（클라이언트 또는 서버) 속도를 낮춤
  - 각 TCP 연결이 네트워크 대역폭을 공평하게 공유할 수 있게끔 제한
  - (추가) 긴 메시지를 짧은 메시지로 나누고 네트워크가 혼잡할 때 출발지의 전송률을 줄이는 것
- +) TCP의 보안화 : TLS
  - TCP나 UDP는 암호화 제공X
  - ㄴ-> 인터넷 커뮤니티는 TCP를강화한 TLS(Transport Layer Security)를 개발
  - TLS로 강화된 TCP는 암호화, 데이터 무결성, 종단 인증을 포함하는 보안 서비스 제공
  - 프로토콜이 아님. 애플리케이션 계층에서 구현된 것,
  - ㄴ-> TLS 서비스를 위해 애플리케이션의 클라이언트, 서버 모두 TLS 코드를 포함해야함.
  - 전통적인 TCP 소켓 API와 유사한 자신의 소켓 API를 갖고 있다.
  1. 송신 프로세스는 평문 데이터를 TLS 소켓에게 전달
  2. 송신 호스트에 있는 TLS는 데이터를 암호화하고 암호화된 데이터를 TCP 소켓으로 전달
  3. 암호화된 데이터는 수신 프로세스에 있는 TCP 소켓까지 인터넷을 타고 전달
  4. 수신 소켓은 암호화된 데이터를 TLS로 전달되고 데이터의 암호를 해독
  6. TLS는 TLS 소켓을 통해 평문 데이터를 수신 프로세스로 전달
  
  HTTPS(Hypertext Transfer Protocol Secure)는 HTTP 프로토콜의 보안 버전
  HTTPS는 SSL/TLS(Secure Sockets Layer/Transport Layer Security) 프로토콜을 사용하여 통신을 암호화하고 인증이 가능하다.
UDP 서비스
- 최소의 서비스 모델을 가진 간단한 전송 프로토콜
- 비연결형 = 핸드셰이킹X
- 비신뢰적인 데이터 전송 서비스를 제공
- 순서 보장 X
- 혼잡제어 X -> UDP의 송신 측은 데이터를 원하는 속도로 보낼 수 있다

인터넷 트랜스포트 프로토콜이 제공하지 않는 서비스
- 오늘날 인터넷은 서비스 같은거 없어도 시간 or 대역폭의 보장을 제공할 수는 없지만 웬만하면 잘 작동한다~
- 많은 방화벽이 UDP 트래픽을 차단하도록 설정되어 있기 때문에，인터넷 전화 애플리케이션은 UDP 통신이 실패할 경우를 대비하여 TCP를 사용하도록 설계되어 있다

📧 2.1.5 애플리케이션 계층 프로토콜

애플리케이션 계층 프로토콜 : 다른 종단 시스템에서 실행되는 애플리케이션의 프로세스가 서로 메시지를 보내는 방법(아래 내용)을 정의
- 교환 메시지 타입（예: 요청 메시지와 응답 메시지）
- 여러 메시지 타입의 문법（예: 메시지 내부의 필드와 필드 간의 구별 방법）
- 필드의 의미，즉 필드에 있는 정보의 의미
- 언제，어떻게 프로세스가 메시지를 전송하고 메시지에 응답하는지 결정하는 규칙
네트워크 애플리케이션 != 애플리케이션 계층 프로토콜
- 애플리케이션 계층 프로토콜 < 네트워크 애플리케이션
  (애플리케이션 계층 프로토콜은 네트워크 애플리케이션의 한 요소)
- ex)
  - 네트워크 애플리케이션 : 웹 (사용자가 필요에 따라 웹 서버로부터 문서 제공)
  - 웹 애플리케이션 : 문서 포맷 표준（HTML), 웹 브라우저, 웹 서버（ex 아파치) 등
    => 웹 애플리케이션 계층 프로토콜인 HTTP는 메시지의 포맷과 순서를 정의 = HTTP는 단지 웹 애플리케이션의 한 요소

📖 2.1.6 이 책에서 다루는 네트워크 애플리케이션

5개의 주요 애플리케이션 분야（웹，전자메일，디렉터리 서비스，비디오 스트리밍，KP 애플리케이션）을 다룸

웹
- 매우 인기 있는 애플리케이션
- 애플리케이션 계층 프로토콜（HTTP）이 이해하기 쉽고 간단
전자메일
- 인터넷의 첫 번째 킬러 애플리케이션
- 여러 애플리케이션 계층 프로토콜을 사용 = 복잡
DNS
- 인터넷을 위한 디렉터리 서비스를 제공
- 대부분의 사용자는 DNS와 직접 상호작용X but 사용자는 다른 애플리케이션을 통해 간접 제어
- 코어 네트워크 기능(네트워크 이름을 네트워크 주소로 변환)
P2P 파일 공유 애플리케이션
비디오 스트리밍 온디맨드 : CDN（content distribution network) 상에서의 저장 비디오 배분

🕸 2.2 웹과 HTTP

📑 2.2.1 HTTP 개요

HTTP(HyperText Transfer Protocol)

웹의 애플리케이션 계층 프로토콜
메시지의 구조 및 클라이언트와 서버가 메시지를 어떻게 교환하는지에 대해 정의
클라이언트 프로그램과 서버 프로그램으로 구현됨.
클라이언트/서버 프로그램(서로다른 종단시스템)은 HTTP 메시지를 교환하여 통신

용어 정리

웹 페이지(문서): 객체들로 구성
객체(object) : 단순히 단일 URL로 지정할 수 있는 하나의 파일(HTML 파일，JPEG 이미지，자바스크립트，CCS 스타일 시트 파일，비디오 클립 등)
- 보통 기본 HTML 파일과 여러 참조 객체로 구성
  - 기본 HTML 파일은 페이지 내부의 다른 객체를 그 객체의 URL로 참조한다.
  - 각 URL은 2개의 요소，즉 객체를 갖고 있는 서버의 호스트 이름과 객체의 경로 이름을 가짐
    ex) http://www.someSchool.edu/someDepartment/picture.gi
    - 호스트 이름: www.someSchool.edu
    - 객체 경로 이름 :/someDepartment/picture.gif
웹 브라우저 : HTTP의 클라이언트 측 구현 ~= 클라이언트
- 요구한 웹 페이지를 보여주고 여러 가지 인터넷 항해와 구성 특성을 제공
웹 서버(Webserver) : HTTP의 서버 측을 구현
- URL로 각각을 지정할 수 있는 웹 객체를 가짐.
- ex) 아파치, 마이크로소프트 인터넷 인포메이션 서버 등
HTTP: 웹 클라이언트가 웹 서버에게 웹 페이지를 어떻게 요청하는지와 서버가 클라이언로 어떻게 웹 페이지를 전송하는지를 정의
HTTP, TCP 사용에 있어서 통신 과정
1. 사용자가 웹 페이지를 요청
2. 브라우저는 페이지 내부의 객체에 대한 HTTP요청 메시지를 서버에 전송
3. 서버는 요청을 수신하고 객체를 포함하는 HTTP 응답메시지로 응답한다.
4. HTTP는 TCP를 전송 프로토콜 사용 - HTTP 클라이언트는 먼저 서버에 TCP 연결을 시작
5. 브라우저(클라이언크)와 서버 프로세스는 그들의 소켓 인터페이스를 통해 TCP로 접속
6. 클라이언트는 HTTP 요청 메시지를 소켓 인터페이스로 전송
  - 클라이언트 측의 소켓 인터페이스는 클라이언트 프로세스와 TCP 연결 사이에서의 출입구
7. HTTP 서버는 요청 메시지를 받고 응답 메시지 전송을 소켓 인터페이스를 통해 이뤄짐.
  - 서버 측의 소켓 인터페이스는 서버 프로세스와 TCP 연결 사이에서의 출입구
8. 클라이언트는 소켓 인터페이스로부터 HTTP 응답 메시지를 받는다.
계층구조의 장점 : 위 과정에서 HTTP는 데이터의 손실, TCP 서비스를 생각할 필요X
비상태 프로토콜(stateless protocol) : HTTP의 가장 큰 특성중 하나로, 서버는 클라이언트에 관한 어떠한 상태정보도 저장X

🤝🏻2.2.2 비지속 연결과 지속 연결

비지속 연결 : 요구/응답 쌍이 분리된 TCP 연결을 통해 전송
지속 연결 : 모든 요구와 해당하는 응답들이 같은 TCP 연결을 통해 전송
둘 다 되는 HTTP로 알아보쟈~

비지속연결 HTTP(HyperText Transfer Protocol)
ex) 웹 페이지를 서버에서 클라이언트로 전송하는 단계에서
페이지가 기본 HTML 파일과 10개의 JPEG 이미지로 구성되고, 이 객체들은 같은 서버에 존재
기본 HTML 파일의 URL : http://www.someSchool.edu/someDepartment/home.index
연결 수행 과정
1. HTTP 클라이언트는 HTTP의 기본 포트 번호 80을 통해 www. someSchool.edu 서버로 TCP 연결 시도
  TCP 연결과 관련하여 클라이언트와 서버에 각각 소켓이 있게 됨.
2. HTTP 클라이언트는 1단계에서 설정된 TCP 연결 소켓을 통해 서버로 HTTP 요청 메시지 전송
  이 요청 메시지는 /someDepartment/home.index 경로 이름을 포함
3. HTTP 서버는 1단계에서 설정된 연결 소켓을 통해 요청 메시지 수신 저장장치로부터 /someDepartment/home.index 객체를 추출
  ,HTTP메시지에 그 객체를 캡슐화
  ,그리고 응답 메시지를 소켓을 통해 클라이언트에 전송
4. HTTP 서버는 TCP에게 TCP 연결을 끊는것 요청
5. HTTP 클라이언트가 응답 메시지를 받으면，TCP 연결이 중단된다.
  ,메시지는 캡슐화된 객체가 HTML 파일인 것을 나타낸다.
  ,클라이언트는 응답 메시지로부터 파일 추출
  ,HTML 파일을 조사하고 10개의 JPEG 객체에 대한 참조를 찾는다
6. 그 이후에 참조되는 각 JPEG 객체에 대해 처음 네 단계(클라이언트 전송과같음)를 반복
위는 서버가 객체를 보낸 후에 각 TCP 연결이 끊어지므로 비지속 연결
HTTP/1.0 : 비지속 연결, 각 TCP 연결은 하나의 요청 메시지와 하나의 응답 메시지만 전송
위에서는 사용자가 웹 페이지를 요청할 때 11개의 TCP 연결이 만들어짐.
- 동시 연결을 사용하여 응답 시간을 줄일 수 있음.
RTT : 작은 패킷이 클라이언트->서버->클라이언트 과정까지의(전송/수신) 걸리는 시간
- 패킷 전파 지연，중간 라우터와 스위치에서의 패킷 큐잉 지연，패킷 처리 지연 등을 포함
세 방향 핸드셰이크
1. 클라이언트가 작은 TCP 메시지를 서버로 전송
2. 서버는 작은 메시지로 응답
이때 1 RTT가 계산됨.
3. 클라이언트가 다시 서버에게 응답
일단 요청 메시지가 서버에 도착하면 서버는 HTML 파일을 TCP 연결로 보낸다.
이 HTTP 요청/응답은 1 RTT를 필요로 한다.
총 응답 시간 = 2 RTT + HTML 파일을 서버가 전송하는 데 걸리는 시간
단점
- 각 요청 객체에 대한 새로운 연결이 설정, 유지
TCP 버퍼가 할당, TCP 변수들이 클라이언트와 서버 양쪽에 유지되어야 한다.
이는 수많은 클라이언트들의 요청을 동시에 서비스하는 웹 서버에게 심각한 부담
- 둘째，앞서 언급한 대로 각 객체는 2 RTT를 필요로 함
(TCP 연결 설정에 1 RTT, 객체를 요청하고 받는 데 1 RTT）.

지속연결 HTTP(HyperText Transfer Protocol)
H1TP/1.1 : 지속 연결
- 서버는 응답을 보낸 후에 TCP 연결을 그대로 유지
- 같은 서버의 여러 웹 페이지들을 하나의 지속 TCP 연결을 통해 전송 가능
- 파이프라이닝 : 진행 중인 요청에 대한 응답을 기다리지 않고 연속해서 응답 가능
HTTP 서버는 타임아웃 기간 동안 사용되지 않으면 연결을 닫음
HTTP 디폴트 모드 : 파이프라이닝을 이용한 지속 연결

📧 2.2.3 HTTP 메시지 포맷

HTTP 요청 메시지, HTTP 응답 메시지 이 2개의 포맷을 보쟈~

HTTP 요청 메시지
예시 함 보고시작하자~

GET /somedir/page.html HTTP/1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/5.0
Accept-language: fr

요청 라인 : HTTP 요청 메시지의 첫 줄
- 3개의 필드를 가짐 - method 필드，URL 필드，HTTP 버전 필드
  - method 필드 : GET, POST, HEAD, PUT, DELETE 등
헤더 라인 : 이후의 줄들
- host : 객체가 존재하는 호스트를 명시
  - 이는 웹 프록시 캐시에서 필요로 함.
- Connection: 브라우저는 서버에게 지속 연결 사용 여부
- User-agent: 사용자 에이전트=서버에게 요청을 하는 브라우저 타입을 명시
  - 서버가 같은 객체의 다른 버전을 다른 브라우저에 보낼 수 있으므로 유용
- Accept-language : 사용자가 원하는 객체의 언어（서버에 존재한다면)
  - 없으면 기본 버전을 전송함
  - HTTP에서 사용 가능한 많은 콘텐츠 협상 헤더 중 하나

HTTP 요청 메시지의 일반 포맷

GET 방식 : 자원을 요청할 때 사용
- body 비워둠 -> body 넣으면 POST ^^
- 보통 GET 방식을 사용하고 요청된 URL의 입력 데이터（폼필드들）를 전송함
- ex) GET 방식에서 두 필드의 입력값이 monkeys와 bananas라면
  확장된 URL : www.somesite.com/animalsearch?monkeys&bananas
POST 방식 : 데이터 생성이나 업데이트와 같은 데이터 처리를 요청
- HTTP 클라이언트는 사용자가 폼을 채워 넣을 때 body에 입력하는 해당 방식 사용
HEAD 방식 : 보통 디버깅을 위해 사용(애플리케이션 개발자)
- GET 방식과 유사
- 서버가 HEAD 방식을 가진 요청을 받으면 HTTP 메시지로 응답하는데，요청 객체는 보내지X
PUT 방식 : 웹 서버에 업로드할 객체를 필요로 하는 애플리케이션에 의해 사용
- 리소스 대체, 없으면 생성
DELETE 방식 : 사용자 또는 애플리케이션이 웹 서버에 있는 객체를 지우는 것을 허용

HEAD 방식은 처음봤는데 저 뒤쪽에 웹캐싱 부분에서 웹 캐싱에 있는 내용이면 웹서버에서는 요청 객체없이 응답만 하자나. 그때 쓰지 않을까라고 생각을 쪼끔 해봤슴둥. (디버깅떄 쓴다했지만,,)

HTTP 응답 메시지
예시 함 보고시작하자~

HTTP/1.1 200 OK
Connection: close
Date: Tuez 18 Aug 2015 15:44:04 GMT
Server: Apache/2.2.3 （CentOS）
L크st-Mod丄fied: Tue, 18 Aug 2015 15:11:03 GMT
Content-Length: 6821
Content-Type: text/html
（데이터 데이터 데이터 데이터 데이터 ...）

3개의 섹션 : 초기 상태 라인(status line), 6개의 헤더 라인，개체 몸체로 이루어짐.
- 상태 라인 - 3개의 필드 : 프로토콜 ‘버전 필드’，'상태 코드’，‘해당 상태 메시지’를 가짐.
- 헤더라인
  1. Connection: close： 클라이언트에게 메시지를 보낸 후 TCP 연결을 닫는데 사용
  2. Date： HTTP 응답이 서버에 의해 생성되고 보낸 날짜와 시간
  - ~~객체의 생성, 수정된 시간~~
  3. Server： 메시지가 만들어진 웹 서버(여기서는 아파치)
  - HTTP 요청 메시지의 User-agent: 헤더 라인과 비슷하다.
  4. Last-Modified: 객체가 생성되거나 마지막으로 수정된 시간과 날짜
  - 객체를 로컬 클라이언트와 네트워크 캐시 서버(프록시 서버) 캐싱에 매우 중요하다.
  5. Content-Length： 송신되는 객체의 바이트 수
  6. Content-Type： 개체 몸체 내부의 객체 타입(여기서는 HTML 텍스트)
  - 객체 타입은 파일 확장자로 나타내는 것이 아니라 공식적으로 Content-type: 헤더로 나타낸다.
- body는 요청 객체（데이터 데이터 데이터 데이터 데이터 . . .로 표현된 부분）를 포함

HTTP 응답 메시지의 일반 포맷

상태코드
- 200 OK：요청이 성공했고，정상적으로 정보가 응답 전송 완료
- 301 Moved Permanently：요청 객체가 이동
  - 새로운 URL은 응답 메시지의 Location: 헤더에 나와 있다.
  - 클라이언트 소프트웨어는 자동으로 이 새로운 URL을 추출한다.
- 400 Bad Request: 클라이언트의 잘못된 요청(서버가 요청을 이해X 일반 오류 코드)
- 404 Not Found：요청 문서가 서버에 존재하지 않는다.
- 505 HTTP Version Not Supported: 요청 HTTP 프로토콜 버전을 서버가 지원하지 않는다.
  
  200 번째 성공!
  300 리다이렉트!
  400 클라이언트 실수
  500 서버 실수

🍪 2.2.4 사용자와 서버 간의 상호작용: 쿠키

HTTP 서버는 상태 유지X = 사용자 접속 제한, 사용자 따라 콘텐츠 제공 못함.
-> 이에 대한 해결안 = 쿠키
쿠키 : 쿠키는 사이트가 사용자를 추적 가능하도록 함.
- 비상태 HTTP 위에서 사용자 세션 계층을 생성하는 데 이용 가능
- 사용자 사생활 침해로 논쟁 됨
  요소
  1. HTTP 응답 메시지 쿠키 헤더 라인
  2. HTTP 요청 메시지 쿠키 헤더 라인
  3. 사용자의 브라우저에 사용자 종단 시스템과 관리를 지속시키는 쿠키 파일
  4. 웹사이트의 백엔드(back-end) 데이터베이스
비록 서버는 클라이언트의 이름을 알 수는 없지만, 1678 사용자가 어느 페이지를，어떤 순서로，몇 시에 방문했는지 정확히 알 수 있다.
- 쇼핑몰에서 클라이언트는 구매 목록을 유지할 수 있고, 세션이 끝날 때 총괄하여 지불 가능
클라이언트가 일주일 후에 재 접속하면, 브라우저는 Cookie: 1678을 헤더 라인에 넣어 요청 메시지를 보내고, 이전에 정보를 기반으로 제품 추천이 가능하다.
클라이언트가 회원가입을 한다면 쇼핑몰은 DB에 추가하고, 쿠키의 식별번호를 클라이언트와 연관 O

클라이언트의 브라우저에 key-value쌍으로 저장되는 작은 데이터입니다. 이는 로그인 상태를 유지하고 식별할 수 있습니다.
1. 서버가 클라이언트로 부터 요청을 받았을 떄, 클라이언트에 관한 정보를 토대로 쿠키를 구성
2. 서버는 클라이언트에게 보내는 응답의 헤더에 쿠키를 담아 전송
3. 클라이언트가 응답을 받으면, 브라우저는 쿠키를 쿠키 디렉터리에 저장

👛 2.2.5 웹 캐싱

웹 캐시(프록시 서버) : 기점 웹 서버(origin Webserver)를 대신하여 HTTP 요구를 충족시키는 네트워크 개체
- 자체의 저장 디스크를 갖고 있어 최근 호출된 객체의 사본을 저장 및 보존
- 아래처럼 브라우저는 사용자의 모든 HTTP 요구가 웹 캐시에 가장 먼저 보내지도록 구성 가능
- 브라우저가 설정되면 객체에 대한 각각의 브라우저 요청은 웹 캐시에 가장 먼저 보내진다.
- ex)콘텐츠 전송 네트워크(Content Distribution Network, CDN=넷플릭스)의 사용
  - CDN 회사는 인터넷 전역을 통해 지역적으로 분산된 캐시를 설치 -> 많은 트래픽을 지역화
- ex) http: //www. someschool. edu/campus. gift 라는 객체를 요청할 때 발생 과정
  1. 브라우저 -> 웹 캐시로 TCP 연결 설정, 웹 캐시에 있는 객체에 대한 HTTP으로 요청
  2. 웹 캐시는 객체의 사본이 자기에게 저장되어 있는지 확인
    if 저장되어있다면 웹 캐시-> 클라이언트 브라우저로 HTTP 응답 메시지와 객체를 전송
    else 웹 캐시가 객체를 갖고 있지 않다면, 아래 수행
  3. 웹 캐시 -> 기점 서버인 www.someschool.edu로 TCP 연결을 설정 +
    , 웹 캐시는 캐시와 서버 간의 TCP 연결로 객체에 대한 HTTP 요청 +
    , 기점 서버 -> 웹 캐시로 HTTP 응답 메시지와 함께 객체 전송
  4. 웹 캐시가 객체를 수신할 때，객체를 지역 저장장치에 복사 +
    , 웹 캐시 -> 클라이언트 브라우저에 HTTP 응답 메시지와 함께 객체의 사본 전송
    （클라이언트 브라우저와 웹 캐시 사이에 이미 설정된 TCP 연결을 통해)
- 일반적으로 웹 캐시는 isp가 구입하고 설치
  ex) 대학교 - 캠퍼스 네트워크에 웹 캐시를 설치, 모든 캠퍼스의 브라우저가 이 캐시로 요청
- 장점
  - 클라이언트의 요청에 대한 응답 시간↘
    - 클라이언트-기점 서버 병목 대역폭 << 클라이언트-캐시 병목 대역폭(속도) -> 더욱 효과적
  - 한 기관에서 인터넷으로의 접속하는 링크상의 웹 트래픽을 대폭↘
    - 트래픽↘ = 기관（회사나 대학）은 자주 대역폭을 개선할 필요X 비용↘
    - 인터넷 전체의 웹 트래픽↘ = 모든 애플리케이션을 위한 성능↗

조건부 GET
- 웹 캐싱의 문제 : 캐시 내부에 있는 객체의 복사본 != 새것 (데이터 업데이트 버전:캐싱<서버)
- 해결=조건부 GET
  - HTTP가 가지는 방식
  - 클라이언트가 브라우저로 전달되는 모든 객체가 최신의 것임을 확인하면서 캐싱하도록
  - HTTP 요청 메시지가 아래 2조건을 갖춘다면 조건부 GET 메시지
  (1) GET 방식을 사용
  (2) If-Modified-Since: 헤더 라인 포함
  
  A(클라이언트), B(클라이언트) , 유정(웹 캐싱), 짱구(서버)라 가정하자
  0 단계
  9월 09일 수요일날 유정인 지금 아무 것도 모르는데, A가 유정이한테 와서
  A : 너 짱구랑 친하지? 너 이번달에 짱구 봤어? 철수랑 유리랑 뭔사이야?
  유정 : 읭? 나 모르는데 ㄱㄷㄱㄷ 짱구한테 물어봄
- 동작 과정
1. 브라우저의 요청을 대신해 프록시 캐시는 -> 웹 서버로 요청메시지 전송
```
  ```
    GET /fruit/kiwi.qif HTTP/1.1
    Host: www.exotiquecu丄sine.com
  ```
```
  1단계
  유정: 얌마 짱구야 유리랑 철수랑 사귐??
2. 웹 서버 -> 캐시에게 객체를 가진 응답 메시지를 보낸다.
```
HTTP/1.1 200 0K
Date: Sat, 3 Oct 2015 15:39:29
Server: Apache/1.3.0 (Unix)
Last-Modified: Wed, 9 Sep 2015 09:23:24
Content-Type: image/gif
(데이터 데이터 데이터 데이터 데이터 ...》 
```
  2단계
  짱구 : ㅇㅇ 철수랑 유리랑 사귀던데 오늘(09.09) 가져온 따근한 정보임
  Last-Modified: Wed, 9 Sep 2015 09:23:24
3. 캐시 -> 요청 브라우저에게 객체 전달 + 자신에 객체를 저장
  * 중요한 것은 캐시가 객체와 더불어 마지막으로 수정된 날짜를 함께 저장.
  
  3단계
  유정 : 오쒸 철수랑 유리랑 그러코 그런사이였써? 09.09 일기써야지
  Last-Modified: Wed, 9 Sep 2015 09:23:24
  ..
  유정 : ㅇㅇ 사귄대
  A : ㅇ0ㅇ!!
4. 일주일 후에 다른 브라우저가 같은 객체를 캐시에게 요청하면 객체는 여전히 저장되어있음.
  - 이 객체는 지난주에 웹서버에서 수정됐으므로 브라우저는 조건부 GET으로 갱신조사를 수행
  - 특히，브라우저는 다음과 같은 내용을 보낸다.
  - If-modified-since: = Last-Modified:
  - 아래 조건부 GET은 서버에게 그 객체가 명시된 날짜 이후 수정된 경우만 그 객체를 보내라함.
```
   ```
      GET /fruit/kiwi.gif HTTP/1.1
      Host: www.exotiquecuisine.com
      If-modified-since: Wed, 9 Sep 2015 09:23:24	
   ```
```
  4단계 일주일 후.. 09.09 -> 09.16
  B : 유정아 니 철수랑 유리랑 뭔 사인지 앎?
  유정 : ㅇㅇ 나근데 저번주 09.09날 들었는데 오늘(09.16)은 모름 헤어졌을 수 도?
  B: ㅇ-ㅇ?
  따릉따룽 B가 짱구한테 저나함
  B : 얌마! 쨩구 09.09 이후에 철수 유리 사이에 대한 수정된 최신 정보 있음?(If-modified-since: Wed, 9 Sep 2015 09:23:24) 철수랑 유리랑 뭔 사이임?
5. 변경되지 않았다면 웹 서버 -> 클라이언트에게 다음과 같은 응답 메시지를 보낸다.
```
   ```
      HTTP/1.1 304 Not Modified
      Date: Sat, 10 Oct 2015 15:39:29
      Server: Apache/1.3.0 (Unix)
      《빈개체 몸체》
   ```
```
  5단계
  짱구 : 그거 유정이한테 말했을 때랑 달라진거 없음 -0- (If-modified-since: = Last-Modified:)
  금마 알고있음(Not Modified) 또 말하기 귀찮으니까 니 옆에 있는 유정이한테 물어보셈;;(304) 폰빠떄리 아까움 ㅡㅡ
- 조건부 GET에 대해 웹 서버 응답 메시지 보냄 but 요청된 객체를 포함X -> 대역폭 절약
- 404 Not Modified : 클라이언트에게 요청 객체의 캐싱된 복사본을 사용하라는 것을 의미

📄 2.2.6 HTTP/2

HTTP/2의 주요 목표
- 하나의 TCP 연결상에서 멀티플렉싱 요청/응답 지연 시간↘
- 요청 우선순위화
- 서버 푸시
- HTTP 헤더 필드의 효율적인 압축 기능 등
- HOL(Head of Line) 블로킹 문제를 해결하기 위해 하나의 웹 페이지를 전송하기 위한 병렬 TCP의 수를 줄이거나 제거
  - ㄴ 아래 HTTP/1.1 과 달리 소켓↘ + TCP 혼잡제어 가능
클라이언트와 서버 간의 데이터 포맷 방법과 전송 방법을 변경한 것
<-> HTTP/1.1
- 지속적인 TCP 연결을 이용, 웹 페이지당 오직 하나의 TCP 연결
  ㄴ-> 서버에서의 소켓 수↘, 전송되는 각 웹 페이지는 공정한 네트워크 대역폭을 가짐
- but! 하나의 TCP상에서 웹 페이지의 모든 객체를 보내면 HOL(Head of Line) 블로킹 문제 발생
- HOL(Head of Line) 블로킹 문제 : 큰놈 먼저 보내면 뒤에 작은애들 졸라 기다려야 함.
- HTTP/1.1 는 여러개(6개까지) TCP 연결해서 이를 해결함. + 더 많은 대역폭

HTTP/2 프레이밍

각 메시지를 작은 프레임으로 자르고，같은 TCP 연결에서의 요청과 응답 메시지를 끼워 넣기 = 인터리빙
이후 반대편에서 재조립
1. 서버가 HTTP 응답을 보낼 때, 응답은 프레이밍 서브 계층에 의해 처리되며 프레임들로 나눠짐.
2. 응답의 헤더 필드는 하나의 프레임이 되며 메시지 본문은 하나의 프레임으로 쪼개진다
3. 서버의 프레이밍 서브 계층에서 응답 프레임들이 끼워진 후, 하나의 지속적인 TCP 연결에서 전송
4. 클라이언트에 도착하면 프레이밍 서브 계층에서 모두 재조립되며 브라우저에 의해 처리됨.
1. 마찬가지로，클라이언트의 HTTP 요청은 프레임으로 쪼개지고 끼워짐.
+) 프레이밍 서브 계층은 프레임을 비이너리 인코딩도 함.
- 바이너리 프로토콜은 파싱하기에 더 효율적,더 작은 프레임 크기，에러에 더 강건

메시지 우선순위화 및 서버푸싱

메시지 우선순위화(message prioritization) : 개발자이 요청들의 상대적 우선
순위를 조정 -> 애플리케이션의 성능을 최적화
클라이언트가 여러개 동시요청，각 메시지에 1~256 사이의 가중치를 부여 -> 요청에 우선순위를 매김
높은 수치일수록 높은 우선순위 -> 가장 높은 우선순위의 요청을 위한 프레임 먼저
특정 클라이언트 요청에 대해 여러 개의 응답을 전송 가능
- 원래 응답 외에도 서버는 추가적인 객체를 클라이언트에게 푸시
- 한 객체에 대한 HTTP 요청을 기다리는 대신 서버는 HTML 페이지를 분석 + 필요 객체들 식별
- 해당 객체들에 대한 요청이 도착하기도 전에 해당 객체들을 클라이언트로 전송 -> 추가지연 없앰

HTTP/3

QUIC
- 트랜스포트 프로토콜
- UDP 프로토콜 위에 위치하는 애플리케이션 계층에 구현
- 메시지 멀티플렉싱(인터리빙)，스트림별 흐름 제어，저지연 연결 확립 등 여러 특징 가짐
HTTP/3
- QUIC 위에서 작동하도록 설계된 새로운 HTTP 프로토콜
- 표준화된 상태는 아님
- HTTP/2 특징들은 QUIC에 의해 포함 -> HTTP/3은 훨씬 더 간단한 설계

📨 2.3 인터넷 전자메일

주요 요소
- 사용자 에이전트(user agent) : 사용자가 메시지를 읽고, 응답하고，전달하고，저장하고，구성하게 함.
  - ex) 애플 메일，웹 기반 지메일 등
- 메일 서버(mail server) : 전자메일 인프라스트럭처의 중심
  - 메일박스（mailbox) : 메일 서버안에 있으며, 사용자에게 온 메시지를 유지, 관리
  - 송신자의 사용자 에이전트 -> 송신자의 메일 서버-> 수신자의 메일 서버 -> 수신자의 메일박스에 저장
  - 메일 서버 고장에 대비
    - 송신자가 수신자의 서버로 전달할 수 없다면, 송신자는 메시지 큐에 메시지를 보관하고, 나중에 재전달 시도 -> 여러번 팅기면 송신자에게 알림
- SMTP(Simple Mail Transfer Protocal)
  - 인터넷 전자메일을 위한 주요 애플리케이션 계층 프로토콜
  - TCP의 신뢰적인 데이터 전송 서비스를 이용
  - 클라이언트(송신자 메일 서버)와 (수신자 메일 서버)를 가짐
  - 클라이언트와 서버 모두가 모든 메일 서버에서 수행

🤙🏻 2.3.1 SMTP

SMTP는 여러 가지 장점이 있지만, 오래된 기술이다.
- 모든 메일 메시지의 몸체（헤더뿐 아니라）는 단순한 7비트 ASCII여야 한다 = 전송용량 제한
- 아스키 변환 졸라해야함 -- but HTTP는 변환하지 않지 -> 최근 ㅈ댐
송신 과정
앨리스는 송신자. 밥은 수신자.
1. 송신자는 전자메일 사용자 에이전트를 수행해서 수신자의 전자메일 주소 적고, 메시지를 작성하고 수신자 사용자 에이전트에게 메시지를 보내라고 명령
2. 송신자 사용자 에이전트는 메시지를 송신자의 메일 서버에게 보내고 그곳에서 메시지는 메시지 큐에 놓인다.
3. 송신자의 메일 서버에서 동작하는 SMTP의 클라이언트 측은 메시지 큐에 있는 매시지를 보고, 수신자의 메일 서버에서 수행되고 있는 SMTP 서버에게 25번 포트로 TCP 연결을 설정한다.
4. 초기 SMTP 핸드셰이킹 이후에 SMTP 클라이언트는 송신자의 메시지를 TCP 연결로 보낸다.
이때 SMTP 클라이언트(송신측)는 송신자의 전자메일 주소와 수신자의 전자메일 주소를 제공한
5. 수신자의 메일 서버 호스트에서 SMTP의 서버 측은 메시지를 수신한다. 수신자의 메일 서버는 그 메시지를 수신자의 메일박스에 놓는다.
6. 수신자은 편한 시간에 그 메시지를 읽기 위해 사용자 에이전트를 시동한다.

SMTP는 메일을 보낼 때 두 메일 서버가 먼 거리에 떨어져 있더라도 직접연결. (메일서버 사용X)
SMTP 클라이언트(C)와 SMTP 서버(S) 사이의 메시지 전달 과정의 예
- 클라이언트 : crepes.fr / 서버 : hamburger.edu
- 아래는 TCP 연결이 되자마자 시작
- 클라이언트는 5개의 명령，HELO(HELLO의 약자)，MAIL FROM, RCPT TO, DATA, QUIT 명령을 함.

                        S : 220 hamburger.edu
                        C: HELO crepes.fr
                        S: 250 Hello crepes.fr, pleased to meet you
                        C: MAIL FROM <alice@crepes.fr>
                        S: 250 alice@crepes.fr ... Sender ok
                        C: RCPT TO <bob@hamburger . edu>
                        S: 250 bob@hamburger.edu ... Recipient ok
                        C: DATA
                        S: 354 Enter mail z end with " .on a line by itself
                        C: Do you like ketchup?
                        C: How about pickles?
                        C: .										//끝내쟈!
                        S: 250 Message accepted for delivery
                        C: QUIT
                        S: 221 hamburger.edu closing connection

📄 2.3.2 메일 메시지 포맷

각 헤더 라인은 키워드，콜론，값의 순서로 구성 + 읽을 수 있는 텍스트를 포함
필수 요소 : From: , To:
선택 요소 : Subject: 헤더 등
위 SMTP 명령과는 （비록 from: , to:처럼 공통 단어가 있기는 하지만）다름!
ㄴ 는 SMTP 핸드셰이킹 프로토콜의 일부, 지금 보는 헤더 라인들은 메일 메시지 자체의 일부
일반 메시지 헤더는 다음과 같다.
메시지 헤더 다음에 빈 줄이 이어지고，그다음에 메시지 몸체（ASCII 문자）

        From: alice@crepes.fr
        To: bob@hamburger.edu
        Subject: Searching for the meaning of life.

🤙🏻 2.3.3 메일 접속 프로토콜

송신자의 사용자 에이전트는 송신자의 메일 서버로 전자메일 메시지를 SMTP 또는 HTTP로 전송
- 아래 그림 처럼 왜 2단계를 거쳐야 함?
  - 메일 서버를 거치지 않으면 송신자의 사용자 에이전트는 목적지 메일 서버에 도달할 수 없기 때문
    송신자는 전자메일을 1. 자신의 메일 서버에 저장, 2. 수신자 메일서버가 받을 때까지 계속 전송 시도
수신자는 자신의 ISP 내부의 메일 서버에 있는 자신의 메시지를 어떻게 얻을 수 있는가?
- 수신자 사용자 에이전트는 메시지를 얻기(PULL) 위해 SMTP(PUSH 프로토콜) 사용 불가
  방법 1. 사용자 에이전트는 밥의 전자메일을 확인하기 위해 HTTP를 사용
  -> SMTP 인터페이스 + HTTP 인터페이스를 가지고 있어야함
  방법 2. 전형적인 메일 클라리언트를 사용(ex 마이크로소프트 아웃룩)
  -> 인터넷 메일 접근 프로토콜(Internet Mail Access Protocol, IMAP) 사용
- HTTP나 IMAP 사용 방법 모두 수신자의 메일 서버에 의해 유지되는 폴더를 관리