[TIL] Day56 #TCP/IP #OSI7Layer #HTTP #Cache

2022.07.13(Wed)

[TIL] Day56
[SEB FE] Day55

이제야 올리는 수욜 TIL,, 네트워크 넘 어려워서 머리에 안 들어온다 🥲

☑️ TCP/IP

📎 Start Network

➰ 회선교환 방식
: 발신자와 수신자 사이에 데이터를 전송할 전용선을 미리 할당하고 연결

• 연결하고자 하는 상대가 다른 상대와 연결 중이라면, 해당 연결이 끊어져야 상대방과 연결 가능 ⭕️
• 특정 회선이 끊어지는 경우엔 처음부터 재연결 필요
  
  👎 단점: 즉시성 떨어짐

➰ 패킷교환 방식
: 패킷 단위로 데이터를 잘게 나누어 전송하는 방식

• 각 패킷엔 출발지와 목적지 정보가 있고, 패킷이 목적지를 향해 가장 효율적인 방식으로 이동 가능
• 특정 회선이 전용선으로 할당되지 않기 때문에 빠르고 효율적으로 데이터 전송 가능 ⭕️

📎 IP / IP Packet

👉 IP(인터넷 프로토콜): 출발지와 목적지 정보를 IP주소로 표기하고, 지정한 IP주소에 패킷(packet) 단위로 데이터 전송

➰ IP 패킷: 전송 데이터를 무사히 전송하기 위해 출발지 IP, 목적지 IP와 같은 정보 포함

1. IP 주소 부여
2. 클라이언트가 서버로 패킷 전달
3. IF 서버가 무사히 데이터 전송 받으면, 클라이언트에 IP 패킷을 이용해 응답 전달

🥲 IP 프로토콜 한계

⌘ 비연결성

• 패킷을 받을 대상이 없거나 서비스 불능 상태여도 그대로 패킷 전송

⌘ 비신뢰성

• 중간에 패킷이 사라질 수 있음
• 패킷이 순서대로 도착하지 않을 수 있음

📎 TCP / UDP

➰ Network Socket
: 프로그램이 네트워크에서 데이터를 송수신할 수 있도록, 네트워크 환경에 연결할 수 있게 만들어진 연결부

1. 메시지 생성
2. Socket 을 통해 HTTP 메시지 전달
3. TCP 정보 생성 (메시지 데이터 포함)
4. IP 패킷 생성 전, TCP 세그먼트 생성
   → 이더넷 프레임워크에 포함되어 서버로 전송됨
5. IP 패킷 생성 (TCP 데이터 포함)

➰ TCP/IP 세그먼트
: IP 패킷의 출발지 IP와 목적지 IP 정보를 보완할 수 있는 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보 등 포함

➰ TCP(Transmission Control Protocol): 전송 제어 프로토콜
: 장치들 사이에 논리적인 접속을 성립하기 위하여 3way handshake를 사용하는 연결지향형 프로토콜

• 연결 지향 (TCP 3way handshake; 가상 연결)
• 데이터 전달 보증
• 순서 보장
• 신뢰할 수 있는 프로토콜

➰ TCP 3 way handshake

1. 클라이언트 → 서버에 접속을 요청하는 SYN 패킷을 보냄
2. 서버 → SYN 요청을 받고 클라이언트에게 요청을 수락한다는 ACK & SYN 가 설정된 패킷 발송
3. 클라이언트가 다시 ACK으로 응답하기를 wait
4. 클라이언트 → 서버에게 ACK을 보내면, 이 이후로부터 연결 성립
   ⇒ 데이터 전송 가능
5. (IF 서버 OFF, 클라이언트는 SYN을 보내고, 서버에서 응답이 없으므로 데이터 전송 ❌)
   ✚ SYN(Synchronize), ACK(Acknowledgment)

✋ TCP는 데이터 전송이 성공적으로 이루어진다면 응답을 돌려주기 때문에 IP패킷 한계인 비연결성 보완 가능!

✋ IF 패킷이 순서대로 도착하지 않는다면, TCP 세그먼트 정보를 토대로 패킷 재전송 요청 가능 ⇒ IP패킷 한계인 비신뢰성 보완 가능

➰ UDP(User Datagram Protocol): 사용자 데이터그램 프로토콜
: IP 프로토콜 + PORT, 체크섬 필드 정보만 추가된 단순한 프로토콜

• 비 연결지향 (TCP 3way handshake ❌)
• 기능 거의 없음
• 신뢰성 ⬇️
• 단순하며, 빠른 속도 보장 (🤷‍♀️ why? 3 way handshake 방식 ❌)
• 데이터 전달 보증 ❌
• 순서 보장 ❌
• 연속성이 중요한 서비스에 자주 사용

✚ HTTP3: UDP 사용 → 커스터마이징 가능 👍

✚ CheckSum: 중복 검사의 형태로, 오류 정정을 통해 공간이나 시간 속에서 송신된 자료의 무결성을 보호하는 단순한 방법

	TCP	UDP
연결지향 여부	연결지향형 프로토콜	비연결지향형 프로토콜
전송 순서 보장	⭕️	❌
데이터 수신 여부 확인	⭕️	❌
신뢰성 & 속도	신뢰성 ⬆️, 속도 ⬇️	신뢰성 ⬇️, 속도 ⬆️
한마디로..?	좋은 기능 다 들어있는 무거운 라이브러리	필요 기능만 들어있는 가벼운 라이브러리

---

☑️ 네트워크 계층 모델

OSI 7계층		TCP/IP 4계층
응용(Application Layer) ex. HTTP, DNS, SSL, SMTP, FIP	- 사용자와의 인터페이스를 제공하는 계층 - 사용자가 실행하는 응용 프로그램	애플리케이션
표현(Presentation Layer) ex. GIF, JPEG, MPEG, MIME, ZIP, ASCLL	- 응용 계층으로 전달하거나 전달받는 데이터를 인코딩 또는 디코딩하는 계층 - 번역기 역할 수행 ex. 문자코드, 압축, 암호화 등의 데이터 변환	애플리케이션
세션(Session Layer) ex. RPC, SQL, NETBOIS, Sockets	- 세션 연결 설정&해제, 세션 메시지 전송 기능 수행 계층 - 컴퓨터간의 통신 방식에 대해 결정하는 계층	애플리케이션
전송(Transport Layer) ex. TCP, UDP, NETBEUI	- 컴퓨터간 신뢰성 있는 데이터를 서로 주고받을 수 있도록 하는 서비스를 제공하는 계층 - 해당 데이터들이 실제로 정상적으로 보내지는지 확인하는 역할 ex. TCP/UDP 연결	전송
네트워크(Network Layer) ex. IP, ICMP	- 네트워크 간에 데이터 라우팅 담당 ✎ 라우팅: 어떤 네트워크 안에서 통신 데이터를 짜여진 알고리즘에 의해 최대한 빠르게 보낼 최적의 경로를 선택하는 과정 ex. IP 패킷 전송	인터넷
데이터 링크(Data Link Layer) ex. FDDI, Ethernet, PPP	- 네트워크 기기 간의 데이터 전송 및 물리주소 결정 계층 - 물리 계층에서 들어온 전기 신호를 모아 데이터 형태로 처리 ex. 브리지, 스위치, MAC 주소	네트워크 인터페이스
물리(Physical Layer) ex. CDMA, GSM, NICs, CSMA/CD, Fiber	- 시스템 간의 물리적 연결과 전기 신호를 변환 및 제어하는 계층 - 주로 물리적 연결과 관련된 정보 정의 - 들어온 전기 신호를 그대로 잘 전달하는 것이 목적 ex. 디지털/아날로그로 신호 변경	네트워크 인터페이스

📎 OSI 7계층 모델

Header: 데이터를 상대방에게 보낼 때 각 계층에서 필요한 정보를 추가한 데이터
👉 즉, 이렇게 헤더를 붙여나가는 것 ⇒ 캡슐화

➰ 데이터 캡슐화

• 각 계층은 독립적 → 데이터가 전달되는 동안에 다른 계층 영향 ❌
• 데이터 전송측: 상위 → 하위 계층으로 데이터 전달
  

➰ 역캡슐화: 상위 계층으로 데이터를 전달하며, 각 계층에서 헤더를 제거해 나가는 것

📎 TCP/IP 4계층 모델

: 실용성에 기반을 둔 현대의 인터넷 표준

4️⃣ 계층	애플리케이션 계층	- TCP/UDP기반의 응용 프로그램을 구현할 때 사용 ex. FTP, HTTP, SSH
3️⃣ 계층	전송 계층	- 통신 노드간의 연결을 제어하고, 신뢰성 있는 데이터 전송 담당 ex. TCP/UDP
2️⃣ 계층	인터넷 계층	- 통신 노드 간의 IP 패킷을 전송하는 기능 및 라우팅 담당 ex. IP, ARP, RARP
1️⃣ 계층	네트워크 인터페이스 계층	- 물리적인 주소로 MAC 사용 ex. LAN, 패킷망

➰ Client: 서비스 요청측
➰ Server: 서비스 제공측

---

☑️ HTTP

HTTP/1.1, HTTP/2 👉 TCP 기반 프로토콜
HTTP/3 👉 UDP 기반 프로토콜

📎 HTTP 특징

1. 클라이언트 서버 구조

   • Request-Response 구조
   • 클라이언트 → 서버에 요청을 보내고, 응답 대기
   • 서버 → 요청에 대한 결과를 만들어 응답

2. 무상태 프로토콜 (Stateless)

   • 비연결성으로 인해 서버가 클라이언트 상태를 기억하지 못하는 속성
   • 서버 → 클라이언트 상태 보존 ❌
     • 👍 서버 확장성 ⬆️ (스케일 아웃 - 수평 확장 유리)
     • 👎 클라이언트 → 추가 데이터 전송

   ➰ Stateful vs Stateless

   • Stateful(상태유지)
     • 항상 같은 서버가 유지되어야 한다!!
     • IF 서버 장애 발생 → 다른 서버에서 응답 전달하면 되기 때문에 클라이언트는 다시 요청할 필요 ❌
     • ex. Login → 브라우저 쿠키, 서버 세션, 토큰 등을 이용해서 상태 유지
   • Stateless(무상태)
     • 아무 서버나 호출해도 된다!! (요청시 이미 필요한 데이터를 다 담아서 보내기 때문)
     • IF 서버 장애 발생 → 유지되던 상태 정보 다 증발 → 첨부터 다시 서버에 요청 😭
     • 갑자기 클라이언트 요청 증가 → 서버 대거 투입 가능 ⭕️
     • 응답 서버를 쉽게 바꿀 수 있음 → 무한한 서버 증설 가능 ⭕️
     • ex. Login이 필요없는 단순 서비스 소개 화면

3. 비연결성 (Connectionless)

   • 응답이 완료되면 클라이언트와 서버 연결이 끊어지는 속성
   • HTTP는 연결을 유지하지 않는 모델
   • 일반적으로 초 단위 이하의 빠른 속도로 응답
   • 수천명이 서비스를 사용해도 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음
     (트래픽이 많지 않고, 빠른 응답을 제공할 수 있는 경우)

   ➰ Connection Oriented (연결 유지 모델)
   : TCP/IP의 경우 기본적으로 서버 연결 유지 ⭕️
   → 서버 자원 계속 소모
   
   ➰ Connectionless (연결을 요지하지 않는 모델 - 비연결성)
   : HTTP에선 실제로 요청을 주고받을 때만 연결 유지하고, 응답을 주고 나면 TCP/IP 연결 끊음
   → 서버 연결 유지 ❌, 최소한의 자원 사용

   ➰ 비연결성 한계 극복

   • TCP/IP 연결을 새로 맺어야 함 (3way handshake 시간 추가)
   • 웹 브라우저로 사이트 요청 → HTML, JS, CSS, 추가 이미지 등 많은 자원 함께 다운로드
   • 지금은 HTTP 지속 연결(Persistent Connections)로 문제 해결
     • 연결 이후, 각 자원들을 요청하고 모든 자원에 대한 응답이 돌아온 후 연결 종료
   • HTTP/2, HTTP/3에서 더 많은 최적화

4. HTTP 메세지

5. 단순하며, 확장 가능

📎 HTTP 헤더

✎ HTTP 메시지 - Header & Body로 구분

➰ HTTP Body
: 데이터 메시지 본문(Message body)을 통해서 표현 데이터 전달

✚ Payload: Message body
✚ 표현(Representation): 요청이나 응답에서 전달할 실제 데이터
✚ 표현 헤더: 표현 데이터를 해석할 수 있는 정보 제공

➰ HTTP Header
: HTTP 전송에 필요한 모든 부가정보를 담기 위해 사용

✎ Header 형식
<field-name>: <field-value>
✋ field-name은 대소문자 구분 ❌

➰ 표현 헤더

• Content-Type: 표현 데이터 형식
  • ex. 미디어 타입, 문자 인코딩
    • Text/html; charset-utf-8
    • application/json
• Content-Encoding: 표현 데이터 압축 방식
  • 데이터 전달하는 곳에서 압축 후 → 인코딩 헤더 추가
  • 데이터를 읽는 쪽에서 인코딩 헤더 정보로 압축 해제
• Content-Language: 표현 데이터의 자연 언어
  • ko, en, en-US
• Content-Length: 표현 데이터 길이
  • Byte 단위
  • Transfer-Encoding(전송시 어떤 인코딩 방법 사용할 것인지)와 함께 사용 ❌

  ✋ 표현 헤더는 요청, 응답 둘 다 사용

➰ 요청(Request)에서 사용되는 헤더

1. From: User Agent의 email 정보

2. Referer: 이전 웹 페이지 주소 (유입 경로 수집 가능)

3. User-Agent: User Agent Application 정보

4. Host: 요청한 Host 정보 (Domain)

5. Origin: 서버로 POST 요청을 보낼 때, 요청을 시작한 주소

   ✋ 요청 보낸 주소 & 받는 주소가 다르면 CORS error 발생

6. Authorization: 인증 토큰을 서버로 보낼 때 사용하는 헤더

   • 토큰 종류 + 실제 토큰 문자 전송

➰ 응답(Response)에서 사용되는 헤더

1. Server: 요청을 처리하는 ORIGIN 서버의 SW 정보
2. Date: 메시지 발생 날짜&시간
3. Location: Page Redirection
   • 201(created): Location 값은 요청에 의해 생성된 Resource URI
   • 3xx(Redirection): Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스
4. Allow: 허용 가능한 HTTP 메서드
   • 405(Method Not Allowed)에서 응답에 포함
5. Retry-After: User Agent가 다음 요청을 하기까지 기다려야 하는 시간
   • 503(Service Unavailable): 서비스가 언제까지 불능인지 알림 가능

➰ 콘덴츠 협상 헤더
: 클라이언트가 선호하는 표현 요청

• Accept: 클라이언트 선호 미디어 타입 전달
• Accept-Charset: 클라이언트 선호 문자 인코딩
• Accept-Encoding: 클라이언트 선호 압축 인코딩
• Accept-Language: 클라이언트 선호 자연 언어
  • 우선순위 설정 가능 (1~0)
  • Accept-Language: ko-KR, ko;q=0.9, en-US;q=0.8, en;q=0.7

 ✋ 협상 헤더는 요청시에만 사용

---

☑️ Web Cache

➰ 캐시(Cache): 데이터나 값을 미리 복사해 놓는 임시 장소
👉 캐시에 데이터 미리 복사시, 더 빠른 속도로 데이터 접근 가능

⌘ 브라우저 캐시 저장시 헤더에 cache-control 속성을 이용해 캐시 유효 시간 지정 가능
👉 Cache-Control: max-age=60 (60초 동안 해당 캐시 유효)

🥲 캐시가 없을 때

• 데이터가 변경되지 않아도 계속 네트워크를 통해 데이터를 다운로드 받아야함
• 인터넷 네트워크는 매우 느리고 비쌈
• 브라우저 로딩 속도 느림
• 느린 사용자 경험 제공
  
  

🙂 캐시 적용

• 캐시 가능 시간동안 네트워크 사용하지 않아도 됨
• 비싼 네트워크 사용량 줄일 수 있음
• 브라우저 로딩 속도 매우 빠름
• 빠른 사용자 경험 제공

⏰ IF 캐시 시간 초과 경우
: 서버를 통해 데이터 다시 조회 → 캐시 갱신 → 다시 네트워크 다운로드 발생 → 캐시 유효 시간 다시 초기화

📎 캐시 검증 헤더

➰ 검증 헤더(Validator) - Last Modified

• 캐시 수정시간 알 수 있음
• 데이터가 마지막으로 수정된 시간 정보를 헤더에 포함
  ⇒ 응답 결과를 캐시에 저장할 때 데이터 최종 수정일도 저장
  
  ✚ 캐시 유효시간이 초과되더라도 If-Modified-Since 헤더를 이용해 조건부 요청 가능 ⭕️

1. 데이터가 수정되었는지 검증
2. IF 수정 ❌ → Body 제외한 HTTP 헤더만 전송
3. 브라우저 캐시에서 응답 결과 재사용 & 헤더 메타데이터 갱신
4. 브라우저 → 캐시에서 조회한 데이터 렌더링

✅ Last-Modified & If-Modified-Since Summary

• IF 캐시 유효 시간 초과 But, 서버 데이터 갱신 ❌
  ⇒ 304 Not Modified + 헤더 메타데이터만 응답 (Body ❌)
• [Client] 서버가 보낸 응답 헤더 정보로 캐시 메타데이터 갱신
• [Client] 캐시에 저장되어 있는 데이터 재활용
• 네트워크 다운로드는 발생 But, 용량이 적은 헤더 정보만 다운로드
• Very 실용적인 해결책!!

👎 Last-Modified & If-Modified-Since 단점

• 1초 미만 단위로 캐시 조정 불가능 ❌
• 날짜 기반 로직 사용
• 같은 데이터를 수정해서 날짜는 다르지만, 데이터 결과가 같은 경우
• 서버에서 별도 캐시 로직 을 관리하고 싶은 경우

➰ ETag(Entity Tag) & If-None-Match

• 서버에서 완전히 캐시 컨트롤하고 싶은 경우 → ETag 사용 가능
• 캐시용 데이터에 임의의 고유 버전 이름 달아둠
• 데이터 변경시 이름 변경 → Hash 다시 생성
• 단순히 ETag만 보내서 같으면 유지, 다르면 다시 받는 방식임
• 캐시 제어 로직을 서버에서 완전히 관리

✋ 서버에서 별도 캐시 로직을 관리하고 싶은 경우 → ETag 사용

1. [Server] 헤더에 ETag를 작성해 응답
2. 클라이언트의 캐시에서 해당 ETag 값 저장
3. IF 캐시 시간 초과로 재요청 → ETag 값을 검증하는 If-None-Match를 요청 헤더에 작성해서 보냄
4. 서버에서 데이터 변경 ❌ → ETag 동일 → If-None-Match 거짓
5. [Server] 304 Not Modified 응답 → HTTP Body ❌
6. 브라우저 캐시에선 응답 결과 재사용 & 헤더 데이터 갱신

 ✋ 캐시 유효시간이 초과되더라도 If-None-Match 헤더를 이용해 조건부 요청 가능

➰ Cache-Control (캐시 지시어)

• Cache-Control: max-age: 캐시 유효 시간 (초 단위)
• Cache-Control: no-cache: 데이터는 캐시해도 되지만, 항상 Origin 서버에 검증하고 사용
• Cache-Control: no-store: 데이터에 민감 정보가 있으므로 저장 ❌

➰ Expires (캐시 만료일 지정)

• 캐시 만료일을 정확한 날짜로 지정
• HTTP 1.0부터 사용
• 현재는 Cache-Control: max-age 권장
• max-age와 함께 사용시 Expires 무시됨

검증헤더(Validator)	조건부 요청 헤더
ETag	If-Match, If-None-Match
Last-Modified	If-Modified-Since, If-Unmodified-Since

📎 프록시 캐시

➰ 프록시(Proxy): 클라이언트와 서버 사이에 대리로 통신을 수행하는 것
➰ 프록시 서버: 그 중계 기능을 하는 서버

👉 다른 네트워크에 간접적 접속 가능 →
👍 보안, 캐싱을 통한 성능, 트래픽 분산 장점

• 클라이언트와 원 서버 사이에 프록시 캐시 서버를 도입하면 빠른 속도로 자료 가져옴

➰ private 캐시: 클라이언트에서 사용하고 저장하는 캐시 (default)
➰ public 캐시: 프록시 캐시 서버의 캐시

➰ 프록시 캐시 관련 Header

• Cache-Control: public - 응답이 public 캐시로 저장
• Cache-Control: private - 응답이 해당 사용자만을 위함, private 캐시에 저장
• Cache-Control: s-maxage - 프록시 캐시에만 적용되는 max-age
• Age: 60 (HTTP 헤더) - 원 서버에서 응답 후 프록시 캐시 내에 머문 시간(초)

➰ 캐시 무효화 가능 Header

• Cache-Control: no-cache: 데이터는 캐시해도 되지만, 항상 Origin 서버에 검증하고 사용 → 검증 후 304 응답
• Cache-Control: no-store: 데이터에 민감 정보가 있으므로 저장 ❌
• Cache-Control: must-revalidate
  • 캐시 만료 후 최초 조회시 원서버에 검증
  • 원서버 접근 실패시 반드시 오류 발생해야함 → 504(Gateway Timeout)
• Pragma: no-cache: HTTP 1.0 하위 호환

🤔 IF 프록시 캐시 서버 & 원 서버 간 네트워크 연결 단절 → 원서버 접근 불가능,

• [no-cache] 응답으로 오류 대신 오래된 데이터라도 보여주자!! → 캐시 데이터 사용 가능 → 200 OK
• [must-revalidate] 응답으로 504 Gateway Timeout Error