네트워크

ian·2023년 1월 20일

OSI 7 Layer, TCP IP model
DNS
HTTP & REST API

DNS

OSI 7 Layer

Reason

Easy for troubleshooting the network problems.

TCP/IP model

payload, header on Layer

2 Frames, Mac
3 Packets, IP
4 Segments, Port

Network Layer

Routing

네트워크 계층에서 가장 중요한 기능은 데이터를 목적지까지 안전하고 빠르게 전달하는 기능입니다.
네트워크 계층은 여러개의 노드를 거칠때마다 경로를 찾아주는 역할
라우팅 알고리즘을 통해 경로를 선택해 주소를 정하고 경로에 따라 패킷을 전달합니다.

Dynamic
Static

LAN table
패킷의 목적지가 같은 네트워크에 있는지 아니면 다른 네트워크에 있는지를 확인한다.

Network table
패킷을 전달할 네트워크 주소를 찾아낸다.

Routing table
가장 적합한 경로를 찾아내서 패킷을 보낸다.

IP

unreliability, connectionlessness
데이터의 재조합이나 손실여부 확인이 불가능하며, 단지 데이터를 전달하는 역할만을 담당

IPv4 Protocol

비신뢰적이고 비연결형인 최선형 전송 서비스
IPv4 패킷이 유실되거나 순서에 맞지 않게 도착할 수 있다
10진법

IPv6 Protocol

IPv4의 주소 고갈, IP 패킷의 형태 변경, ICMP와 같은 몇몇 보조 프로토콜의 수정을 위해 고안된 새로운 버전의 프로토콜입니다.
기존의 32-bit의 주소는 128-bit로 확장
16진법

Transport Layer

TCP

Flow control

It makes sure that the receiver will not be overwhelmed with data.

The data link layer in the OSI model is responsible for facilitating flow control.

The flow control mechanism tells the sender the maximum speed at which the data can be sent to the receiver device

흐름제어 (endsystem 대 endsystem)
송신측과 수신측의 데이터 처리 속도 차이를 해결하기 위한 기법
Flow Control은 receiver가 packet을 지나치게 많이 받지 않도록 조절하는 것
기본 개념은 receiver가 sender에게 현재 자신의 상태를 feedback 한다는 점

Congestion control

:TCP Slow-Start and Congestion Avoidance

3-way-handshake

이전의 connection으로부터 오는 패킷으로 인식할 수 있다.
이러한 문제가 발생할 가능성을 줄이기 위해 ISN을 난수로 설정하는 것이다.

UDP
It speeds up communications by not formally establishing a connection before data is transferred. This allows data to be transferred very quickly, but it can also cause packets to become lost in transit — and create opportunities for exploitation in the form of DDoS attacks.

TCP vs UDP

HTTP

비연결성 (Connectionless)
클라이언트에서 서버에 요청을 하고 서버가 요청을 받아 응답하게 되면 연결을 끊어버리는 특징
HTTP 1.1 부턴 지속적 연결 상태가 기본

무상태성 (Stateless)
비연결성(Connectionless)에서 파생되는 특징으로 각각의 요청이 독립적으로 여겨지게 되는 특징
서버는 클라이언트의 상태(State)를 유지하지 않으므로 Cookie, Session 등을 이용하여 클라이언트 인증, 인식을 한다

HTTP/1.1
1.0에서는 연결하고 끊고를 반복하면 서버나 클라이언트 모두에 부담이 된다. 그래서 1.1은 pipeline(파이프라인) 기능을 추가하여 매번 연결을 맺고 끊고 하는 과정을 줄여서 속도를 높였다.
PUT, DELETE 등의 새로운 Method가 추가 되었다.

HTTP/1.1의 문제점
HOLB(Head Of Line Blocking)
HTTP 요청을 할 때는 요청을 하고 나서 응답이 와야 다음 요청을 할 수 있었는데 HTTP/1.1에 들어오면서 파이프라이닝(Pipelining) 기법을 통해 응답을 받지 않고도 여러개의 요청을 연속적으로 할 수 있게 되었다. 하지만 이 또한 처음의 요청에 대한 응답이 오래 걸리는 경우, 그 다음 응답까지의 시간이 지연되는 현상이 발생한다. 이렇게 파이프라이닝 기법은 심각한 문제를 안고 있었으며 이를 Head of Line Blocking 문제라고 부른다.

무겁고 중복 많은 헤더 구조
요청을 할 때 요청헤더에 메타정보를 넣어서 보내게 되는데, 매 요청마다 보내는 정보가 많아져서 헤더가 무거워지고 쿠키 같은 경우는 계속 보내게 되기 때문에 중복도 많아지는 문제가 있다.

HTTP/2.0
2012년 구글이 만든 SPDY 프로토콜을 기반으로 만들어진 프로토콜이다. 1.1은 컨넥션 하나에서 여러개의 파일을 전송할 수 있는 1개의 파이프라인을 연결하는데 2.0은 연결이 되면 여러개의 파이프라인을 꽂는다고 생각하면 된다. 이걸 stream(스트림) 이라고 하는데 1번 파이프라인으로 전송되던 파일이 늦어지면 2번, 3번 또는 다른 파이프라인으로 보내기 때문에 늦어지는 현상이 1.1에 비해서 짧다는 장점이 있다.

멀티플렉싱(Multiplexing)과 스트리밍(Streaming)
HTTP 요청 데이터는 헤더와 본문으로 구성되는데 이를 각각 프레임(Frame)이라는 단위로 지정하고 스트림(Stream)이라는 연결단위를 통해 헤더 프레임 혹은 본문 프레임을 보내도록 그 방식을 바꿨다. 하나의 스트림은 요청/응답으로 구성되고 여러개의 스트림을 생성할 수 있다. 바로 이것이 스트리밍을 통한 멀티플렉싱이다. 이를 통해 기존의 HTTP/1.1의 문제점인 HLOB를 해결할 수 있게 된다. 또한 요청한 리소스간의 우선순위를 설정하기 때문에 스트림 별로 가중치가 매겨지고 브라우저가 리소스들을 수신하는 순서를 적절하게 결정한다.

서버 푸시(Server Push)
브라우저가 요청하지 않으면 서버는 응답하지 않는 것이 보통이지만, 요청한 HTML 문서에 리소스가 포함되어 있는 경우 서버가 브라우저에게 밀어주는(push) 방식을 취하여 브라우저의 요청을 최소화시킨다.

헤더 압축(Header Compression)
헤더 테이블(Header Table)을 사용하여 이전 헤더 정보를 유지하고 허프만 인코딩 기법으로 헤더를 압축해서 전송하여 중복과 크기를 줄인다.

URI는 자원의 위치를 알려주기 위한 프로토콜

HTTPS(Hyper Text Transfer Protocol over Secure-Socket-Layer)

HTTP 프로토콜에 대해 SSL 암호화 통신 기능을 추가한 네트워크 프로토콜

HTTPS는 대칭키 암호화를 사용 하며 다음과 같은 과정을 거친다.
클라이언트가 서버에게 접속요청을 하면 서버는 CA에서 발급받은 인증서를 보낸다. 인증서에는 CA의 비밀키로 암호화된 사이트정보와 공개키가 들어있다.
클라이언트는 인증서를 받아 CA의 공개키로 복호화하여 접속요청한 서버가 신뢰할만한지 검증한다.
복호화가 되면 인증서가 신뢰할 만하기 때문에 데이터를 주고받을 대칭키를 생성한다.
대칭키를 서버의 공개키로 암호화하여 서버에게 전송한다.
서버는 자신의 비밀키로 클라이언트가 보낸 대칭키를 복호화한 뒤 그 대칭키를 통해 데이터를 주고받는다.

HTTP METHOD
Safe, Idempotent, Cacheable

HTTP POST과 PUT의 차이

Idempotent