네트워크 심화 과정

---

IP & IP Packet 💥

인터넷 내부에서 클라이언트와 서버가 통신하는 법

 

IP(인터넷 프로토콜) 주소를 컴퓨터에 부여하여 이를 사용

패킷 단위로 전송을 하면 노드들은 목적지 IP에 도달하기 위해 서로 데이터를 전달

 

IP

지정한 IP 주소(IP Address)에 패킷(Packet)이라는 통신 단위로 데이터 전달

 

IP Packet

pack + bucket의 합성어 패킷!
우체국 송장처럼 전송 데이터를 무사히 전송하기 위해 출발지 IP, 목적지 IP와 같은 정보가 포함되어 있다.

 

IP의 한계점

비연결성

 

패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷을 전송해버린다..

 

비신뢰성 

 

중간에 패킷이 사라질 수 있다!

 

패킷의 순서를 보장할 수 없다.

Ex. 전달 데이터의 용량이 큰 경우 패킷 단위로 나눠 전달
-> 서로 다른 노드 통해 전달되며 의도되지 않은 순서로 패킷이 도착해버릴 수 있다.

 

TCP vs UDP 🔥

 

Ex. 채팅 프로그램에서 메시지를 보내는 경우
- HTTP 메시지가 생성됨
- Socket 라이브러리를 통해 전달
- IP 패킷을 생성하기 전 TCP 세그먼트를 생성
- 생성된 TCP/IP 패킷은 LAN 카드와 같은 물리적 계층을 지나기 위해 이더넷 프레임 워크에 포함되어 서버로 전송

 

TCP

전송 제어 프로토콜 (Transmission Control Protocol )

 

연결지향형 - 3 way handshake

클라이언트 -> 서버 / 접속 요청하는 SYN 패킷 전송
서버 -> 클라이언트 / 클라이언트에게 SYN + ACK 설저된 패킷 발송
클라이언트 -> 서버 / 서버에게 ACK 보냄( 연결 성립, 데이터 전송 가능 )

IP 패킷의 한계인 비연결성을 보완
-> 데이터 전송이 성공적으로 이루어진다면 이에 대한 응답을 돌려준다.

IP 패킷의 비신뢰성을 보완
-> 패킷이 순서대로 도착하지 않는다면 TCP 세그먼트에 있는 정보를 토대로 다시 패킷 전송을 요청한다.

 

UDP

사용자 데이터그램 프로토콜

 

IP 프로토콜에 PORT, 체크섬 필드 정보만 추가된 단순한 프로토콜 (체크섬: 중복 검사의 한 형태)

HTTP3 -> UDP를 사용, 이미 여러 기능이 구현된 TCP보다는 흰 도화지처럼 커스터마이징이 가능하다는 장점

 

TCP	UDP
연결지향형 프로토콜	비 연결지향형 프로토콜
전송 순서 보장	전송 순서 보장 X
데이터 수신 여부 확인	데이터 수신 여부 확인 X
신뢰성 👍🏻 속도 👎🏻	신뢰성 👎🏻 속도 👍🏻

좋은 기능이 다 들어있는 무거운 라이브러리 (TCP) vs 필요한 기능만 들어있는 가벼운 라이브러리 (UDP)

 

HTTP 💻

 

HTTP/1.1, HTTP/2는 TCP 기반이며 HTTP/3은 UDP 기반 프로토콜

 

HTTP의 특징

단순하고 확장 가능하다.
클라이언트 서버 구조
무상태성(Stateless)

상태 유지(Stateful):
점원A가 고객의 상태를 기억하고 있는 것
->항상 같은 서버가 응답해야 -> 서버에 장애가 난다면 유지되던 상태정보 날라감, 처음부터 서버에 다시 요청해야 함

무상태(Stateless):
(고객이 자신의 주문을 기억하고 있다면) 중간에 다른 점원으로 바뀌어도 주문을 할 수 있다.
고객(클라이언트 요청)이 증가하더라도 무상태에서는 점원(서버)을 대거 투입할 수 있다
-> 응답 서버를 쉽게 바꿀 수 있다 -> 무한한 서버 증설 가능

 

한계 :
로그인이 필요없는 단순한 서비스 소개 화면 -> 무상태로 설계가능
로그인이 필요한 서비스 -> 유저의 상태 유지해야 함(브라우저쿠키,서버세션,토큰 등 이용 상태 유지)

 

비연결성(Connectionless)

요청을 주고 받을 때만 연결을 유지하고 응답을 주고 나면 TCP/IP 연결을 끊음 -> 최소한의 자원으로 서버 유지
HTTP 지속 연결(Persistant Connections)
연결이 이루어지고 난 뒤 각각의 자원들을 요청하고 모든 자원에 대한 응답이 돌아온 후에 연결 종료

 

HTTP 메세지

HTTP 메시지는 헤더와 바디로 구분

 

HTTP body: message body(=payload) 통해 표현 데이터 전달
HTTP header : 표현 데이터를 해석할 수 있는 정보 제공( HTTP 전송에 필요한 모든 부가정보)

 

표현헤더

요청, 응답 둘 다 사용

Content-Type : 표현 데이터의 형식
Content-Encoding : 표현 데이터의 압축 방식
Content-Language : 표현 데이터의 자연 언어
Content-Length : 표현 데이터의 길이

 

콘텐츠 협상

동일한 URI에서 리소스의 서로 다른 버전을 서브하기 위해 사용되는 메커니즘 - 가장 잘 맞는 프레젠테이션의 결정

 

협상헤더
-요청시에만 사용

캐시(cache)
데이터나 값을 미리 복사해 놓는 임시 장소

캐시의 접근 시간에 비해 원래 데이터를 접근하는 시간이 오래 걸리는 경우나 값을 다시 계산하는 시간을 절약하고 싶은 경우에 사용
요청 - 응답을 받았을 때 브라우저 캐시에 해당 응답 결과를 저장하며 이는 지정한 시간동안 유효

캐시 유효 시간 초과 : 다시 서버에 요청을하고 지정 시간동안 유효한 이미지를 응답받음 -> 네트워크 다운로드

 

검증 헤더(Validator), 조건부 요청 헤더

1. Last Modified & If-Modified-Since

Last Modified : 데이터가 마지막으로 수정된 시간정보를 헤더에 포함
If-Modified-Since : 캐시 유효시간 초과되더라도 조건부 요청

2. ETag & If-None-Match

3. 프록시 캐시

한국에 있는 클라이언트에서 특정 데이터가 필요한 상황인데 해당 데이터의 원 서버가 미국에 있다고 가정(ex-youtube)

클라이언트와 원 서버 사이에 위치한 프록시 캐시 서버를 도입
private 캐시 : 클라이언트에서 사용하고 저장하는 캐시프록시 캐시
public 캐시 : 서버의 캐시

클라이언트가 캐시를 적용하지 않아도 임의로 브라우저가 캐시를 적용하는 경우

---