5. Network

아현·2021년 10월 8일

Computer Science

목록 보기

6/47

1. OSI 7 계층

참고, 참고2, 참고3

OSI 모형(Open Systems Interconnection Reference Model)은 국제표준화기구(ISO)에서 개발한 모델로, 컴퓨터 네트워크 프로토콜 디자인과 통신을 계층으로 나누어 설명한 것이다.
- 일반적으로 OSI 7 계층이라고 한다.
이 모델은 프로토콜을 기능별로 나눈 것이다.
- 각 계층은 하위 계층의 기능만을 이용하고, 상위 계층에게 기능을 제공한다.
- '프로토콜 스택' 혹은 '스택'은 이러한 계층들로 구성되는 프로토콜 시스템이 구현된 시스템을 가리키는데, 프로토콜 스택은 하드웨어나 소프트웨어 혹은 둘의 혼합으로 구현될 수 있다.
  - 일반적으로 하위 계층들은 하드웨어로, 상위 계층들은 소프트웨어로 구현된다.

7계층은 왜 나눌까?
- 통신이 일어나는 과정을 단계별로 알 수 있다.
- 특정한 곳에 이상이 생기면 그 단계만 수정할 수 있기 때문이다.

1) 물리(Physical) 계층

물리 계층(Physical layer)은 네트워크의 기본 네트워크 하드웨어 전송 기술을 이룬다.
네트워크의 높은 수준의 기능의 논리 데이터 구조를 기초로 하는 필수 계층이다.
다양한 특징의 하드웨어 기술이 접목되어 있기에 OSI 아키텍처에서 가장 복잡한 계층으로 간주된다.

리피터, 케이블, 허브 등

단지 데이터 전기적인 신호로 변환해서 주고받는 기능을 진행하는 공간
- 즉, 데이터를 전송하는 역할만 진행한다.

2) 데이터 링크(Data Link) 계층

데이터 링크 계층(Data link layer)은 포인트 투 포인트(Point to Point) 간 신뢰성있는 전송을 보장하기 위한 계층
CRC(cyclic redundancy check) 기반의 오류 제어와 흐름 제어가 필요하다.
- 네트워크 위의 개체들 간 데이터를 전달하고, 물리 계층에서 발생할 수 있는 오류를 찾아 내고, 수정하는 데 필요한 기능적, 절차적 수단을 제공한다.
순환 중복 검사 (CRC, cyclic redundancy check)
- 네트워크 등을 통하여 데이터를 전송할 때 전송된 데이터에 오류가 있는지를 확인하기 위한 체크값을 결정하는 방식을 말한다.
주소 값은 물리적으로 할당 받는데, 이는 네트워크 카드가 만들어질 때부터 맥 주소(MAC address)가 정해져 있다는 뜻이다.
- 주소 체계는 계층이 없는 단일 구조이다.
데이터 링크 계층의 가장 잘 알려진 예는 이더넷이다.
- 이 외에도 HDLC나 ADCCP 같은 포인트 투 포인트(point-to-point) 프로토콜이나 패킷 스위칭 네트워크나 LLC, ALOHA 같은 근거리 네트워크용 프로토콜이 있다.
- 네트워크 브릿지나 스위치 등이 이 계층에서 동작하며, 직접 이어진 곳에만 연결할 수 있다.
프레임에 주소부여(MAC - 물리적주소)
에러검출/재전송/흐름제어

브릿지, 스위치 등
물리 계층으로 송수신되는 정보를 관리하여 안전하게 전달되도록 도와주는 역할
Mac 주소를 통해 통신한다.
- 프레임에 Mac 주소를 부여하고 에러검출, 재전송, 흐름제어를 진행한다.

3) 네트워크(Network) 계층

네트워크 계층(Network layer)은 여러 개의 노드를 거칠때마다 경로를 찾아주는 역할을 하는 계층
다양한 길이의 데이터를 네트워크들을 통해 전달하고, 그 과정에서 전송 계층이 요구하는 서비스 품질(QoS)을 제공하기 위한 기능적, 절차적 수단을 제공한다.
네트워크 계층은 라우팅, 흐름 제어, 세그멘테이션(segmentation/desegmentation), 오류 제어, 인터네트워킹(Internetworking) 등을 수행한다.
라우터가 이 계층에서 동작하고 이 계층에서 동작하는 스위치도 있다.
데이터를 연결하는 다른 네트워크를 통해 전달함으로써 인터넷이 가능하게 만드는 계층이다.
- 논리적인 주소 구조(IP), 곧 네트워크 관리자가 직접 주소를 할당하는 구조를 가지며, 계층적(hierarchical)이다.
서브네트의 최상위 계층으로 경로를 설정하고, 청구 정보를 관리한다.
- 개방형 시스템들의 사이에서 네트워크 연결을 설정, 유지, 해제하는 기능을 부여하고, 전송 계층 사이에 네트워크 서비스 데이터 유닛(NSDU : Network Service Data Unit)을 교환하는 기능을 제공한다.
주소부여(IP)
경로설정(Route)

라우터, IP
데이터를 목적지까지 가장 안전하고 빠르게 전달하는 기능을 담당한다.
라우터를 통해 이동할 경로를 선택하여 IP 주소를 지정하고, 해당 경로에 따라 패킷을 전달해준다.
라우팅, 흐름 제어, 오류 제어, 세그먼테이션 등을 수행한다.

4) 전송(Transport) 계층

전송 계층(Transport layer)은 양 끝단(End to end)의 사용자들이 신뢰성있는 데이터를 주고 받을 수 있도록 해 주어, 상위 계층들이 데이터 전달의 유효성이나 효율성을 생각하지 않도록 해준다.
시퀀스 넘버 기반의 오류 제어 방식을 사용한다.
전송 계층은 특정 연결의 유효성을 제어하고, 일부 프로토콜은 상태 개념이 있고(stateful), 연결 기반(connection oriented)이다.
- 이는 전송 계층이 패킷들의 전송이 유효한지 확인하고 전송 실패한 패킷들을 다시 전송한다는 것을 뜻한다.
- 가장 잘 알려진 전송 계층의 예는 TCP이다.
종단간(end-to-end) 통신을 다루는 최하위 계층으로 종단간 신뢰성 있고 효율적인 데이터를 전송하며, 기능은 오류검출 및 복구와 흐름제어, 중복검사 등을 수행한다.
패킷 생성(Assembly/Sequencing/Deassembly/Error detection/Request repeat/Flow control)

TCP, UDP
TCP와 UDP 프로토콜을 통해 통신을 활성화한다. 포트를 열어두고, 프로그램들이 전송을 할 수 있도록 제공해준다.
- TCP : 신뢰성, 연결지향적
- UDP : 비신뢰성, 비연결성, 실시간

5) 세션(Session) 계층

세션 계층(Session layer)은 양 끝단의 응용 프로세스가 통신을 관리하기 위한 방법을 제공한다.
동시 송수신 방식(duplex), 반이중 방식(half-duplex), 전이중 방식(Full Duplex)의 통신과 함께, 체크 포인팅과 유휴, 종료, 다시 시작 과정 등을 수행한다.
- 전이중 방식은 하나의 연결을 통하여 데이터가 동시에 양방향으로 오고 갈 수 있는 방식이다.
- 반이중 방식은 전달에 대한 응답이 도착한 후에 다른 전달을 수행하는 방식이다.

세션 계층은 두 응용 프로세스의 대화를 관리하려고 하는 토큰이라는 특수 메시지를 사용한다.
- 큰 파일 전체를 하나의 단위로 전송하는 것보다 논리적으로 작은 단위로 나누어서 전송하는 것이 오류 발생 시 유리하다. 만약 오류가 발생하면 큰 파일 전체를 한 단위로 보낼 경우 다시 큰 단위를 보내야하지만 작은 단위로 나눌 경우 오류가 난 부분부터 다시 보내게 되면 되기 때문이다. 따라서 세션 계층은 동기점을 사용한다.

이 계층은 TCP/IP 세션을 만들고 없애는 책임을 진다.
통신하는 사용자들을 동기화하고 오류복구 명령들을 일괄적으로 다룬다.
통신을 하기 위한 세션을 확립/유지/중단 (운영체제가 해줌)

API, Socket
데이터가 통신하기 위한 논리적 연결을 담당한다.
- TCP/IP 세션을 만들고 없애는 책임을 지니고 있다.

6) 표현(Presentation) 계층

표현 계층(Presentation layer)은 코드 간의 번역을 담당하여 사용자 시스템에서 데이터의 형식상 차이를 다루는 부담을 응용 계층으로부터 덜어 준다.
MIME 인코딩이나 암호화 등의 동작이 이 계층에서 이루어진다.
- 예를 들면, EBCDIC로 인코딩된 문서 파일을 ASCII로 인코딩된 파일로 바꿔 주는 것이 표현 계층의 몫이다.
사용자의 명령어를 완성 및 결과 표현.
포장 / 압축 / 암호화

JPEG, MPEG 등

데이터 표현에 대한 독립성을 제공하고 암호화하는 역할을 담당한다.
- 파일 인코딩, 명령어를 포장, 압축, 암호화한다.

7) 응용(Application) 계층

응용 계층(Application layer)은 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행한다.
일반적인 응용 서비스는 관련된 응용 프로세스들 사이의 전환을 제공한다.
- 응용 서비스의 예로, 가상 터미널(예를 들어, 텔넷), "Job transfer and Manipulation protocol" (JTM, 표준 ISO/IEC 8832) 등이 있다.
네트워크 소프트웨어 UI 부분
사용자의 입출력(I/O)부분

HTTP, FTP, DNS 등
최종 목적지로, 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행한다.
사용자 인터페이스, 전자우편, 데이터베이스 관리 등의 서비스를 제공한다.

2. TCP 3 way handshake & 4 way handshake

참고, 참고2, 참고3, 참고4

연결을 성립하고 해제하는 과정을 말한다

TCP의 특징

TCP(Transmission Control Protocol)
:인터넷상에서 데이터를 메세지의 형태로 보내기 위해 IP와 함께 사용하는 프로토콜

일반적으로 TCP와 IP를 함께 사용하는데, IP가 데이터의 배달을 처리한다면 TCP는 *패킷을 추적 및 관리하게 됩니다.

TCP는 연결형 서비스를 지원하는 프로토콜로 인터넷 환경에서 기본으로 사용합니다.

참고: UDP(User Datagram Protocol)
:데이터를 데이터그램 단위로 처리하는 프로토콜

데이터그램이란 독립적인 관계를 지니는 패킷이라는 의미

TCP와 달리 UDP는 비연결형 프로토콜입니다.

즉, 연결을 위해 할당되는 논리적인 경로가 없는데, 그렇기 때문에 각각의 패킷은 다른 경로로 전송되고, 각각의 패킷은 독립적인 관계를 지니게 되는데

이렇게 데이터를 서로 다른 경로로 독립적으로 처리하게 되고, 이러한 프로토콜을 UDP라고 합니다.

UDP는 비연결형 서비스이기 때문에, 연결을 설정하고 해제하는 과정이 존재하지 않습니다.

서로 다른 경로로 독립적으로 처리함에도 패킷에 순서를 부여하여 재조립을 하거나 흐름 제어 또는 혼잡 제어와 같은 기능도 처리하지 않기에 TCP보다 속도가 빠르며 네트워크 부하가 적다는 장점이 있지만 신뢰성있는 데이터의 전송을 보장하지는 못합니다.

그렇기 때문에 신뢰성보다는 연속성이 중요한 서비스 예를 들면 실시간 서비스(streaming)에 자주 사용됩니다.

1) 연결형 서비스로 가상 회선 방식을 제공한다.

2) 3-way handshaking과정을 통해 연결을 설정하고 4-way handshaking을 통해 해제한다.

3) 흐름 제어 및 혼잡 제어.

4) 높은 신뢰성을 보장한다.

5) UDP보다 속도가 느리다.

6) 전이중(Full-Duplex), 점대점(Point to Point) 방식.

TCP가 가상 회선 방식을 제공한다는 것은 발신지와 수신지를 연결하여 패킷을 전송하기 위한 논리적 경로를 배정한다는 의미

3-way handshaking과정은 목적지와 수신지를 확실히 하여 정확한 전송을 보장하기 위해서 세션을 수립하는 과정을 의미합니다.
- TCP가 이러한 특징을 지니는 이유 TCP는 연결형 서비스로 신뢰성을 보장하기 때문입니다. 그래서 3-way handshaking의 과정도 사용하는 것이고, 데이터의 흐름제어나 혼잡 제어와 같은 기능도 합니다.
  - 하지만 이러한 기능때문에 UDP보다 속도가 느리게 됩니다.

즉 TCP는 정확한 전송을 보장해야 한다. 따라서 통신하기에 앞서, 논리적인 접속을 성립하기 위해 3 way handshake 과정을 진행한다.

3 way handshake - 연결 성립

양쪽 모두 데이터를 전송할 준비가 되었다는 것을 보장하고, 실제로 데이터 전달이 시작하기전에 한쪽이 다른 쪽이 준비되었다는 것을 알수 있도록 한다.
양쪽 모두 상대편에 대한 초기 순차일련변호를 얻을 수 있도록 한다.

용어
- Client > Server : TCP SYN
- Server > Client : TCP SYN ACK
- Client > Server : TCP ACK
SYN (SYnchronize sequence Numbers)
ACK (ACKnowledgment)

과정
1. A클라이언트는 B서버에 접속을 요청하는 SYN 패킷을 보낸다.
  - 이때 A클라이언트는 SYN 을 보내고 SYN/ACK 응답을 기다리는SYN_SENT 상태가 되는 것이다.
2. 이때 서버는 Listen 상태로 포트 서비스가 가능한 상태여야 한다. (Closed :닫힌상태)
  
  B서버는 SYN요청을 받고 A클라이언트에게 요청을 수락한다는 ACK 와 SYN flag 가 설정된 패킷을 발송하고 A가 다시 ACK으로 응답하기를 기다린다.
  - 이때 B서버는 SYN_RECEIVED 상태가 된다.
3. A클라이언트는 B서버에게 ACK을 보내고 이후로부터는 연결이 이루어지고 데이터가 오가게 되는것이다.
  
  이때의 B서버 상태가 ESTABLISHED 이다.
- 이렇게 3번의 통신이 완료되면 연결이 성립된다.
  (3번이라 3 way handshake인 것)

예시

1번에 seq넘버를 보내고

2번에 ack로 1번인 넘버에 1이 추가되었음을 알 수 있다.

동시에 서버역시 seq넘버를 보낸다

3번 클라이언트의 ack도 서버가 보낸 seq넘버에 1이 더해졌다

이런식으로 랜덤한 숫자를보내고 잘받았다는 ack로 1을 더해주는 방식을 사용한다.

4 way handshake - 연결 해제

연결 성립 후, 모든 통신이 끝났다면 해제해야 한다.

클라이언트는 서버에게 연결을 종료한다는 FIN 플래그를 보낸다.
서버는 FIN을 받고, 확인했다는 ACK를 클라이언트에게 보낸다. (이때 모든 데이터를 보내기 위해 CLOSE_WAIT 상태가 된다)
데이터를 모두 보냈다면, 연결이 종료되었다는 FIN 플래그를 클라이언트에게 보낸다.
클라이언트는 FIN을 받고, 확인했다는 ACK를 서버에게 보낸다. (아직 서버로부터 받지 못한 데이터가 있을 수 있으므로 TIME_WAIT을 통해 기다린다.)
- 서버는 ACK를 받은 이후 소켓을 닫는다 (Closed)
- TIME_WAIT 시간이 끝나면 클라이언트도 닫는다 (Closed)

그런데 만약 "Server에서 FIN을 전송하기 전에 전송한 패킷이 Routing 지연이나 패킷 유실로 인한 재전송 등으로 인해 FIN패킷보다 늦게 도착하는 상황"이 발생한다면 어떻게 될까요?

Client에서 세션을 종료시킨 후 뒤늦게 도착하는 패킷이 있다면 이 패킷은 Drop되고 데이터는 유실될 것입니다.

이러한 현상에 대비하여 Client는 Server로부터 FIN을 수신하더라도 일정시간(디폴트 240초) 동안 세션을 남겨놓고 잉여 패킷을 기다리는 과정을 거치게 되는데 이 과정을 "TIME_WAIT" 라고 합니다.

이렇게 4번의 통신이 완료되면 연결이 해제된다.

3. TCP/IP 흐름제어 & 혼잡제어

OSI 7 Layer vs TCP/IP Protocol

TCP/IP 프로토콜은 OSI 모델보다 먼저 개발되었다. 그러므로 TCP/IP 프로토콜의 계층은 OSI 모델의 계층과 정확하게 일치하지 않는다.

두 계층을 비교할 때 , 세션(Session)과 표현(presentation) 2개의 계층이 TCP/IP프로토콜 그룹에 없다는 것을 알 수 있다.

두 모델 모두 계층형 이라는 공통점을 가지고 있으며 TCP/IP는 인터넷 개발 이후 계속 표준화되어 신뢰성이 우수인 반면, OSI 7 Layer는 표준이 되기는 하지만 실제적으로 구현되는 예가 거의 없어 신뢰성이 저하되어있다.

TCP/IP Protocol

1) Network Access Layer

OSI 7 Layer에서 물리계층과 데이터링크 계층에 해당한다.
OS의 네트워크 카드와 디바이스 드라이버 등과 같이 하드웨어적인 요소와 관련되 는 모든 것을 지원하는 계층
송신측 컴퓨터의 경우 상위 계층으로부터 전달받은 패킷에 물리적인 주소은 MAC 주소 정보를 가지고 있는 헤더를 추가하여 프레임을 만들고, 프레임을 하위계층인 물 리 계층으로 전달한다.

- 수신측 컴퓨터의 경우 데이터 링크 계층에서 추가된 헤더를 제거하여 상위 계층인 네트워크 계층으로 전달한다.

2) Internet Layer

OSI 7 Layer의 네트워크 계층에 해당한다.
인터넷 계층의 주요 기능은 상위 트랜스포트 계층으로부터 받은 데이터에 IP패킷 헤더를 붙여 IP패킷을 만들고 이를 전송하는 것이다.

3) Transport Layer

OSI 7 Layer에서 전송계층에 해당한다.
네트워크 양단의 송수신 호스트 사이에서 신뢰성 있는 전송기능을 제공한다.
시스템의 논리주소와 포트를 가지고 있어서 각 상위 계층의 프로세스를 연결해서 통신한다.
정확한 패킷의 전송을 보장하는 TCP와 정확한 전송을 보장하지 않는 UDP 프로토콜을 이용한다.
데이터의 정확한 전송보다 빠른 속도의 전송이 필요한 멀티미디어 통신에서 UDP 를 사용하면 TCP보다 유용하다.

4) Application Layer

OSI 7 Layer에서 세션계층 , 프레젠테이션계층, 애플리케이션 계층에 해당한다.
응용프로그램들이 네트워크서비스, 메일서비스, 웹서비스 등을 할 수 있도록 표준적 인 인터페이스를 제공한다.

💨 TCP의 가장 큰 특징은 신뢰성이다. 이러한 신뢰성을 구성해 주는 방법인 흐름제어, 혼잡제어, 오류제어에 대해 알아보자.

흐름 제어

송신(호스트) <> 수신(호스트)

흐름제어는 수신측과 송신측의 데이터처리 속도차이를 해결하기 위한 기법이다.

만약 송신측의 전송량 > 수신측의 처리량 일 경우, 전송된 패킷은 수신측의 큐를 넘어서 손실될 수 있기 때문에 송신측의 패킷 전송량을 제어하게 된다.

ACK ?

기본적으로 ACK은 TCP Header에 포함되어있는 4Byte크기의 정수 데이터이다.

TCP 통신에서 ACK은 패킷 도착여부를 확인 하기위해 사용된다.

수신한 패킷의 Sequence Number와 Data의 크기에 따라 ACK 번호가 결정되게 되는데 결정할 때 사용하는 공식은 "SEQ + (Data Size)" 이다.
- 그러나 Data Size가 0이라면 같은 ACK을 반복하게 된다.
- 이를 방지해서 받은 패킷의 Data Size가 0이라면 Sequnce 번호에 1을 더한 값을 ACK으로 설정한 후 패킷을 전달하게 된다.
위 그림은 A가 B에게 패킷을 전달하는 과정이고, 원래는 양방향으로 전달하기 때문에 서로 SEQ, ACK, Data Size를 지속적으로 전달하게 된다.
- 그래서 A는 데이터를 보낸 후 B한테 까지 정상적으로 데이터가 도착했으면 받아야 할 ACK 값인 1461을 받지 못하면 TCP의 에러제어에 의해서 패킷을 재전송 하게된다.
  - 이 때 재전송 하기위해 A는 보낸 패킷을 ACK을 받을 때 까지 보관한다.
  - 마지막으로 A는 다음 SEQ 번호를 가장 최근에 받은 ACK 번호를 사용해서 다음 패킷을 전송한다.

한마디로 B가 A에게 ACK:1461을 전송하는 것의 의미는 "너가 보낸 패킷의 내 대답은 1461이야. 그리고 너 다음 패킷 보낼 때는 Sequence번호를 1461을 사용해서 보내도록 해!" 이다.

흐름 제어

정지-대기(Stop-and-wait)

구조가 간단한 대신, 하나를 주고 응답을 받기 때문에 비효율적이다.

슬라이딩 윈도우(Sliding Window)

윈도우는 전송,수신 스테이션 양쪽에서 만들어진 버퍼(Buffer)의 크기다.
- 윈도우의 크기 = (가장 최근 ACK로 응답한 프레임의 수) - (이전에 ACK 프레임을 보낸 프레임의 수)
슬라이딩 윈도우 기법은 앞의 정지-대기 기법의 비효율성을 개선한 기법이다.
ACK프레임을 수신하지 않더라도, 여러 개의 프레임을 연속적으로 전송할 수 있다.
전송측 윈도우 n-1 개의 프레임을 포함한다.

위와 같은 구조에서 데이터 0, 1을 전송했다고 가정하면 슬라이딩 윈도우의 구조는 다음과 같이 변하며 윈도우의 크기는 전송한 데이터 프레임만큼 줄어들게 된다.

이때 만약 수신측에서 ACK라는 프레임을 받게 된다면 전송측은 0, 1이 데이터를 정상적으로 받았음을 알게 되고, 전송측은 ACK 프레임에 따른 프레임의 수만큼 오른쪽으로 경계가 확장된다.

혼잡 제어

송신(호스트) <> 라우터(네트워크)

혼잡 제어는 송신측과 네트워크의 데이터처리 속도 차이를 해결하기 위한 기법이다.

송신된 패킷이 네트워크 상의 라우터가 처리할 수 있는 양을 넘어서 혼잡하게 되면 데이터가 손실될 수 있기 때문에 송신측의 전송량을 제어하게 된다.

합 증가/곱 감소

이 방식은 AIMD(Additive Increase/Multiplicative Decrease)라고 불리는 방식이다.
처음에 패킷을 하나씩 보내고 이것이 문제없이 도착하면 창 크기(단위 시간 내에 보내는 패킷의 수)를 1씩 증가시켜가면서 전송하는 방법이다.
만일 패킷 전송을 실패하거나 일정한 시간을 넘으면 패킷을 보내는 속도를 절반으로 줄이게 된다.
이 방식은 공평한 방식이다.
이 방식을 사용하는 여러 호스트가 한 네트워크를 공유하고 있으면 나중에 진입하는 쪽이 처음에는 불리하지만 시간이 흐르면 평형 상태로 수렴하게 되는 특징이 있다.
문제점은 초기에 네트워크의 높은 대역폭을 사용하지 못하여 오랜 시간이 걸리게 되고,네트워크가 혼잡해지는 상황을 미리 감지하지는 못한다.
즉, 네트워크가 혼잡해지고 나서야 대역폭을 줄이는 방식이다.

슬로우 스타트(Slow Start)

합 증가/곱 감소 방식이 네트워크의 수용량 주변에서는 효율적으로 작동하지만 처음에 전송 속도를 올리는 데 걸리는 시간이 너무 길다는 단점이 있다.
느린 시작(Slow Start) 방식은 합 증가/곱 감소 방식과 마찬가지로 패킷을 하나씩 보내는 것부터 시작하고, 이 방식은 패킷이 문제없이 도착하면 각각의 ACK 패킷마다 Window size를 1씩 늘린다. 즉, 한 주기가 지나면 Window size가 2배로 된다.
- 따라서 전송 속도는 합 증가/곱 감소와는 다르게 지수 함수 꼴로 증가하게 된다.
- 대신에 혼잡 현상이 발생하면 Window size를 1로 떨어뜨리게 된다.
처음에는 네트워크의 수용량을 예상할 수 있는 정보가 없지만 한번 혼잡 현상이 발생하고 나면 네트워크의 수용량을 어느 정도 예상할 수 있으므로 혼잡 현상이 발생하였던 Window size의 절반까지는 이전처럼 지수 함수 꼴로 창 크기를 증가시키고 그 이후부터는 완만하게 1씩 증가시키는 방식이다.

1) 초기 혼잡 윈도우 크기 1로 전송 = 전송 호스트는 하나의 패킷만 전송

2) 수신 호스트로부터 수신응답을 수신하면 윈도우의 크기를 2로 하여 전송

3) 수신 호스트로부터 수신응답을 수신하면 윈도우의 크기 4로 하여 전송

4) 수신 호스트로부터 수신응답을 수신하면 윈도우의 크기 8로 하여 전송

미리 정해진 임계 값에 도달할 때까지 윈도우의 크기를 2배씩 증가시킨다.
Slow start란 이름을 사용하지만, 매 전송마다 두 배씩 증가하기 때문에 전송되어지는 데이터의 크기는 지수 함수적으로 증가한다.
전송되어지는 데이터의 크기가 임계 값에 도달하면 혼잡 회피 단계로 넘어간다.

혼잡 회피(Congestion Avoidance)

윈도우의 크기가 임계 값에 도달한 이후에 데이터의 손실이 발생할 확률이 높아지게된다.
- 데이터를 전송함에 있어서 조심하는 단계이다.

전송한 데이터에 대한 Ack를 받으면 윈도우의 크기를 1씩 증가시킨다.
전송하는 데이터의 증가를 왕복시간 동안에 하나씩만 증가시킨다.
수신 호스트로부터 일정 시간 동안까지 Ack를 수신하지 못하는 경우
- 타임아웃의 발생 : 네트워크에 혼잡이 발생하였다고 인식
- 혼잡상태로 인식된 경우
  - 윈도우의 크기를, 즉 세그먼트의 수를 1로 줄임
  - 동시에 임계 값을 패킷 손실이 발생하였을 때의 윈도우 크기의 반으로 줄임

빠른 회복(Fast Recovery)

빠른 회복 정책은 혼잡한 상태가 되면 Window size를 1로 줄이지 않고 반으로 줄이고 선형 증가시키는 방법이다.
빠른 회복 정책까지 적용하면 혼잡 상황을 한번 겪고 나서부터는 순수한 합 증가/곱 감소 방식으로 동작하게 된다.

오류 제어

오류 제어 기법은 오류검출(error detection)과 재전송(retransmisstion)을 포함한다.
ARQ(Automatic Repeat Request)기법을 사용하여 프레임이 손상되었거나 손실되었을 경우 재전송을 통해 오류를 복구한다.
ARQ기법은 흐름제어 기법과 관련되어있는데, “정지-대기”는 정지-대기-ARQ로, “슬라이딩 윈도우”는 GBn(Go-Back-n) ARQ 또는 SR(Selective-Reject) ARQ 형태로 구현한다.

ARQ(Automatic Repeat Request) : 신뢰성 있는 데이터 전달을 위해 재전송을 기반으로 한 에러 제어 방식

정지-대기 ARQ

전송스테이션은 수신측에서 보내준 ACK를 받을 때 까지, 프레임의 복사본을 유지한다.
- 식별을 위해 데이터 프레임과 ACK프레임은 각각 0, 1번호를 부여한다.
수신측이 데이터를 받지 못했을 경우, NAK를 보내고, NAK를 받은 송신측은 데이터를 재전송한다.
만약 데이터나 ACK가 분실되었을 경우 일정간격의 시간을 두고 타임아웃이 되면, 송신측은 데이터를 재전송한다.

Go-Back-n ARQ (GBn ARQ)

전송된 프레임이 손상되거나 분실될 경우, 확인된 마지막 프레임 이후로 모두 재전송 하는 기법이다.
슬라이딩 윈도우는 연속적인 프레임 전송 기법이므로, 전송 스테이션은 전송된 모든 프레임의 복사본을 가지고 있어야 하며, ACK와 NAK 모두 각각 구별을 해야한다.
ACK : 다음 프레임을 전송 NAK : 손상된 프레임 자체 번호를 반환
재전송 되는 경우는 다음과 같다.
- NAK 프레임을 받았을 경우
  - 만약, 수신측으로 0부터 5까지의 데이터를 보내었다고 가정한다.
  - 수신측에서 데이터를 받았음을 확인하는 ACK 프레임을 중간 중간 받게 되며, ACK 프레임을 확인한 전송측은 계속해서 데이터를 전송한다.
  - 그러나 만약 수신측에서 데이터 오류 프레임 2를 발견하고 NAK2를 전송 측에 보낸다.
  - NAK2를 받은 전송측은 데이터 프레임2가 잘못 되었다는 것을 알고 데이터를 재전송한다.
  - GBn ARQ의 특징은 바로 이 데이터를 재전송하는 부분이다.
  - GBn ARQ는 NAK(n)을 받아 데이터를 재전송하게 되면, n데이터만을 재전송하는 것이 아닌, n데이터 이후 데이터를 모두 재전송한다.
- 전송 데이터 프레임의 분실
  - GBn ARQ의 특징은 확인된 데이터 이후의 모든 데이터 재전송과 수신측의 폐기이다.
  - 수신측에서 데이터 1을 받았는데 갑자기 다음 데이터 3을 받게 된다면 수신측에서는 데이터 2를 못받았으므로 데이터 3을 폐기하고 NAK2를 전송측에 보낸다.
  - NAK를 받은 전송측은 위의 경우에서와 같이 NAK(n) 데이터부터 모두 재전송을 실시하며 수신측은 기존 받았던 데이터 중 NAK(n)으로 보내었던 대상 데이터 이후의 데이터를 모두 폐기하고 재전송 받는다.
- 지정된 타임아웃내의 ACK 프레임 분실(Lost ACK)
  - 전송스테이션은 분실된 ACK를 다루기 위해, 타이머를 가지고 있다.
  - 전송측에서는 이 타이머의 타임아웃동안 ACK 데이터를 받지 못했을 경우, 마지막 ACK된 데이터부터 재전송한다.

전송측은 NAK 프레임을 받았을 경우, NAK 프레임 번호부터 다시 재전송을 시작한다.
수신측은 원하는 프레임이 아닐 경우 모두 폐기 처리한다.
타임아웃(ACK의 분실)일 경우, 마지막 ACK된 데이터부터 재전송한다.

Selective-Reject(SR) ARQ

GBn ARQ의 재전송되는 프레임 이후의 모든 프레임을 재전송하는 단점을 개선한 방법이다.
SR ARQ는 손상된 분실된 프레임만 재전송한다.
그렇기 때문에 별도의 데이터 재정렬을 수행해야하며, 별도의 버퍼를 필요로 한다.

GBn ARQ 기법과 SR ARQ의 비교

TCP 통신이란?
- 네트워크 통신에서 신뢰적인 연결방식
- TCP는 기본적으로 unreliable network에서, reliable network를 보장할 수 있도록 하는 프로토콜
- TCP는 network congestion avoidance algorithm을 사용

reliable network를 보장한다는 것은 4가지 문제점 존재
1. 손실 : packet이 손실될 수 있는 문제
2. 순서 바뀜 : packet의 순서가 바뀌는 문제
3. Congestion : 네트워크가 혼잡한 문제
4. Overload : receiver가 overload 되는 문제

흐름제어/혼잡제어란?
- 흐름제어 (endsystem 대 endsystem)
  - 송신측과 수신측의 데이터 처리 속도 차이를 해결하기 위한 기법
  - Flow Control은 receiver가 packet을 지나치게 많이 받지 않도록 조절하는 것
  - 기본 개념은 receiver가 sender에게 현재 자신의 상태를 feedback 한다는 점
- 혼잡제어 : 송신측의 데이터 전달과 네트워크의 데이터 처리 속도 차이를 해결하기 위한 기법
전송의 전체 과정
- Application layer : sender application layer가 socket에 data를 씀.
- Transport layer : data를 segment에 감싼다. 그리고 network layer에 넘겨줌.
- 그러면 아랫단에서 어쨋든 receiving node로 전송이 됨. 이 때, sender의 send buffer에 data를 저장하고, receiver는 receive buffer에 data를 저장
- application에서 준비가 되면 이 buffer에 있는 것을 읽기 시작
- 따라서 flow control의 핵심은 이 receiver buffer가 넘치지 않게 하는 것
- 따라서 receiver는 RWND(Receive WiNDow) : receive buffer의 남은 공간을 홍보함

4. UDP

TCP와 UDP는 TCP/IP의 전송계층에서 사용되는 프로토콜이다. 전송계층은 IP에 의해 전달되는 패킷의 오류를 검사하고 재전송 요구 등의 제어를 담당하는 계층이다.

TCP vs UDP

TCP는 Transmission Control Protocol의 약자이고, UDP는 User Datagram Protocol의 약자이다. 두 프로토콜은 모두 패킷을 한 컴퓨터에서 다른 컴퓨터로 전달해주는 IP 프로토콜을 기반으로 구현되어 있지만, 서로 다른 특징을 가지고 있다.

먼저, TCP의 데이터 송신 과정을 살펴보자.

반면, UDP는 일방적이다.

즉, 신뢰성이 요구되는 애플리케이션에서는 TCP를 사용하고 간단한 데이터를 빠른 속도로 전송하고자 하는 애플리케이션에서는 UDP를 사용한다.

TCP
- Connection-oriented protocol(연결지향형 프로토콜)
- Connection by bytestream(바이트 스트림을 통한 연결)
- Congestion / Flow control(혼잡제어, 흐름제어)
- Ordered, Lower speed(순서 보장, 상대적으로 느림)
- Reliable data transmission(신뢰성 있는 데이터 전송 - 안정적)
- TCP packet : Segment(세그먼트 TCP 패킷)
- HTTP, Email, File transfer에서 사용
UDP
- Connection-less protocol(비 연결지향형 프로토콜)
- Connection by messagestream(메세지 스트림을 통한 연결)
- NO Congestion / Flow control(혼잡제어와 흐름제어 지원 X)
- Not ordered, Higer speed(순서 보장되지 않음, 상대적으로 빠름)
- Unreliable data transmission(데이터 전송 보장 X)
- UDP packet : Datagram(데이터그램 UDP 패킷)
출처
- DNS, Broadcasting(도메인, 실시간 동영상 서비스에서 사용)

공통점
- 포트 번호를 이용하여 주소를 지정
- 데이터 오류 검사를 위한 체크섬 존재

차이점

TCP (Transmission Control Protocol)

TCP는 네트워크 계층 중 전송 계층에서 사용하는 프로토콜로서, 장치들 사이에 논리적인 접속을 성립(establish)하기 위하여 연결을 설정하여 신뢰성을 보장하는 연결형 서비스 이다.

TCP는 네트워크에 연결된 컴퓨터에서 실행되는 프로그램 간에 일련의 옥텟(데이터, 메세지, 세그먼트라는 블록 단위)를 안정적으로, 순서대로, 에러없이 교환할 수 있게 한다.

TCP의 특징

연결형 서비스
- 연결형 서비스로 가상 회선 방식을 제공한다.
- 3-way handshaking 과정을 통해 연결을 설정
- 4-way handshaking 을 통해 연결을 해제.
흐름제어(Flow control)
- 데이터 처리 속도를 조절하여 수신자의 버퍼 오버플로우를 방지
  - 송신하는 곳에서 감당이 안되게 많은 데이터를 빠르게 보내 수신하는 곳에서 문제가 일어나는 것을 막는다.
- 수신자가 윈도우크기(Window Size) 값을 통해 수신량을 정할 수 있다.

혼잡제어(Congestion control)
- 네트워크 내의 패킷 수가 넘치게 증가하지 않도록 방지
- 정보의 소통량이 과다하면 패킷을 조금만 전송하여 혼잡 붕괴 현상이 일어나는 것을 막는다.

신뢰성이 높은 전송(Reliable transmission)
- Dupack-based retransmission
  - 정상적인 상황에서는 ACK 값이 연속적으로 전송되어야 한다.
  - 그러나 ACK값이 중복으로 올 경우 패킷 이상을 감지하고 재전송을 요청한다.
- Timeout-based retransmission
  - 일정시간동안 ACK 값이 수신을 못할 경우 재전송을 요청한다.

전이중, 점대점 방식
- 전이중 (Full-Duplex)전송이 양방향으로 동시에 일어날 수 있다.
- 점대점 (Point to Point)각 연결이 정확히 2개의 종단점을 가지고 있다.
=> 멀티캐스팅이나 브로드캐스팅을 지원하지 않는다.

TCP Header 정보

응용 계층으로부터 데이터를 받은 TCP는 헤더를 추가한 후에 이를 IP로 보낸다. 헤더에는 아래 표와 같은 정보가 포함된다.

ACK 제어비트

ACK는 송신측에 대하여 수신측에서 긍정 응답으로 보내지는 전송 제어용 캐릭터
ACK 번호를 사용하여 패킷이 도착했는지 확인한다.
- 송신한 패킷이 제대로 도착하지 않았으면 재송신을 요구한다.

TCP의 연결 및 해제 과정

TCP Connection (3-way handshake)

먼저 open()을 실행한 클라이언트가 SYN을 보내고 SYN_SENT 상태로 대기한다.
서버는 SYN_RCVD 상태로 바꾸고 SYN과 응답 ACK를 보낸다.
SYN과 응답 ACK을 받은 클라이언트는 ESTABLISHED 상태로 변경하고 서버에게 응답 ACK를 보낸다.
응답 ACK를 받은 서버는 ESTABLISHED 상태로 변경한다.

TCP Disconnection (4-way handshake)

먼저 close()를 실행한 클라이언트가 FIN을 보내고 FIN_WAIT1 상태로 대기한다.
서버는 CLOSE_WAIT으로 바꾸고 응답 ACK를 전달한다. 동시에 해당 포트에 연결되어 있는 어플리케이션에게 close()를 요청한다.
ACK를 받은 클라이언트는 상태를 FIN_WAIT2로 변경한다.
close() 요청을 받은 서버 어플리케이션은 종료 프로세스를 진행하고 FIN을 클라이언트에 보내 LAST_ACK 상태로 바꾼다.
FIN을 받은 클라이언트는 ACK를 서버에 다시 전송하고 TIME_WAIT으로 상태를 바꾼다. TIME_WAIT에서 일정 시간이 지나면 CLOSED된다. ACK를 받은 서버도 포트를 CLOSED로 닫는다.

주의

반드시 서버만 CLOSE_WAIT 상태를 갖는 것은 아니다.

서버가 먼저 종료하겠다고 FIN을 보낼 수 있고, 이런 경우 서버가 FIN_WAIT1 상태가 됩니다.

누가 먼저 close를 요청하느냐에 따라 상태가 달라질 수 있다.

UPD Header 정보

응용 계층으로부터 데이터 받은 UDP도 UDP 헤더를 추가한 후에 이를 IP로 보낸다.

TCP 헤더와 다르게 UDP 헤더에는 포함된 정보가 부실한 느낌마저 든다.

UDP는 수신자가 데이터를 받는지 마는지 관심이 없기 때문이다.

즉, 신뢰성을 보장해주지 않지만 간단하고 속도가 빠른 것이 특징이다.

참고

#UDP 통신이란?
- User Datagram Protocol의 약자로 데이터를 데이터그램 단위로 처리하는 프로토콜이다.
- 비연결형, 신뢰성 없는 전송 프로토콜이다.
- 데이터그램 단위로 쪼개면서 전송을 해야하기 때문에 전송 계층이다.
- Transport layer에서 사용하는 프로토콜.

#TCP와 UDP는 왜 나오게 됐는가?
1. IP의 역할은 Host to Host (장치 to 장치)만을 지원한다. 장치에서 장치로 이동은 IP로 해결되지만, 하나의 장비안에서 수많은 프로그램들이 통신을 할 경우에는 IP만으로는 한계가 있다.
2. 또한, IP에서 오류가 발생한다면 ICMP에서 알려준다. 하지만 ICMP는 알려주기만 할 뿐 대처를 못하기 때문에 IP보다 위에서 처리를 해줘야 한다.
- 1번을 해결하기 위하여 포트 번호가 나오게 됐고, 2번을 해결하기 위해 상위 프로토콜인 TCP와 UDP가 나오게 되었다.

ICMP : 인터넷 제어 메시지 프로토콜로 네트워크 컴퓨터 위에서 돌아가는 운영체제에서 오류 메시지를 전송받는데 주로 쓰임

#그렇다면 TCP와 UDP가 어떻게 오류를 해결하는가?

TCP

데이터의 분실, 중복, 순서가 뒤바뀜 등을 자동으로 보정해줘서 송수신 데이터의 정확한 전달을 할 수 있도록 해준다.

UDP

IP가 제공하는 정도의 수준만을 제공하는 간단한 IP 상위 계층의 프로토콜이다. TCP와는 다르게 에러가 날 수도 있고, 재전송이나 순서가 뒤바뀔 수도 있어서 이 경우, 어플리케이션에서 처리하는 번거로움이 존재한다.

#UDP는 왜 사용할까?

UDP의 결정적인 장점은 데이터의 신속성이다. 데이터의 처리가 TCP보다 빠르다.

주로 실시간 방송과 온라인 게임에서 사용된다. 네트워크 환경이 안 좋을때, 끊기는 현상을 생각하면 된다.

#DNS(Domain Name Service)에서 UDP를 사용하는 이유

Request의 양이 작음 -> UDP Request에 담길 수 있다.

3 way handshaking으로 연결을 유지할 필요가 없다. (오버헤드 발생)

Request에 대한 손실은 Application Layer에서 제어가 가능하다.

DNS : port 53번

But, TCP를 사용할 때가 있다! 크기가 512(UDP 제한)이 넘을 때, TCP를 사용해야한다.

DNS과 UDP 통신 프로토콜을 사용

DNS는 데이터를 교환하는 경우다.
- 이때, TCP를 사용하게 되면, 데이터를 송신할 때까지 세션 확립을 위한 처리를 하고, 송신한 데이터가 수신되었는지 점검하는 과정이 필요하므로, Protocol overhead가 UDP에 비해서 큼.

DNS는 Application layer protocol임.
- 모든 Application layer protocol은 TCP, UDP 중 하나의 Transport layer protocol을 사용해야 함.
  - TCP는 reliable, UDP는 not reliable

DNS는 reliable해야할 것 같은데 왜 UDP를 사용할까?
1. TCP가 3-way handshake를 사용하는 반면, UDP는 connection 을 유지할 필요가 없음.
2. DNS request는 UDP segment에 꼭 들어갈 정도로 작음.
  
  DNS query는 single UDP request와 server로부터의 single UDP reply로 구성되어 있음.
3. UDP는 not reliable이나, reliability는 application layer에 추가될 수 있음. (Timeout 추가나, resend 작업을 통해)
  
  DNS는 UDP를 53번 port에서 사용

그러나 TCP를 사용하는 경우가 있다
- Zone transfer 을 사용해야하는 경우에는 TCP를 사용해야 함.
  
  Zone Transfer : DNS 서버 간의 요청을 주고 받을 떄 사용하는 transfer
- 만약에 데이터가 512 bytes를 넘거나, 응답을 못받은 경우 TCP 이용

5. 대칭키 & 공개키

대칭키 (Symmetric Key)

암호화와 복호화에 같은 암호키(대칭키)를 사용하는 알고리즘
하나의 키를 양쪽(client & server)가 같이 사용한다.

장점
- 공개키 암호화 방식에 비해 암호화 및 복호화 속도가 빠르다. 비교적 간편하다.
단점
- 교환 당사자간에 동일한 키를 공유해야하기 때문에 키 관리의 어려움이 있다.
- 잦은 키 변경이 있는 경우 불편하다.
- 암호화 통신을 하는 사용자끼리 같은 대칭키를 공유해야만 한다.
  1. 물리적으로 직접 만나서 전달하지 않는한, 대칭키를 전달하는 과정에서 해킹의 위험에 노출될 수 있다!
    - 관리해야 할 키의 개수가 방대해진다.


# 먼저 cryptography에서 대칭키 암호화를 할 수 있는 Fernet을 import 합니다.

from cryptography.fernet import Fernet

# Fernet.generate_key()를 통해 키를 하나 생성합니다.
# 대칭키 생성

key = Fernet.generate_key()
print('대칭키: ', key)

# 암호화 과정
fernet = Fernet(key)
encrypt_str = fernet.encrypt(b"I want to eat")
print("암호화된 문자열:", encrypt_str)

# 복호화 과정
decrypt_str = fernet.decrypt(encrypt_str)
print('복호화된 문자열:', decrypt_str)

### 출력 ####
# 대칭키:  b'fZTFBgJmhA0POw0gI7A4aeXOyVl_zwf2SvqqVi1JOXg='
# 암호화된 문자열: b'gAAAAABgTw78gay90IYHUR23bKNLddfYmBbKFlL_Mld1zoBAKkkM2PQCx3mqWHNCN3MNZXdb_l3UAj7AAqh0W3EPOdaHYItJSQ=='
# 복호화된 문자열: b'I want to eat'

공개키

암호화와 복호화에 사용하는 암호키를 분리한 알고리즘
공개키와 비밀키 두 개가 존재한다.

공개키(Public Key)만 대중에게 공개하고, 암호화 된 데이터는 고유한 비밀키(Private Key)로만 복호화할 수 있다.
- 이 비밀키를 가진 사용자만이 내용을 열어볼 수 있다.

암호화 방식 진행 과정

A가 웹 상에 공개된 ‘B의 공개키’를 이용해 평문을 암호화하여 B에게 보냄
B는 자신의 비밀키로 복호화한 평문을 확인, A의 공개키로 응답을 암호화하여 A에게 보냄
A는 자신의 비밀키로 암호화된 응답문을 복호화함

장점
- 수신자의 개인키로만 해독할 수 있으므로 안전하다.
단점
- 대칭키(Symmetric Key) 알고리즘에 비하여 속도가 느리다. (약 1000배)
대표 알고리즘 : RSA 등



from Crypto.PublicKey import RSA
from Crypto import Random

# 코드 진행 전 Crypto를 설치해주세요.
# pip install pycryptodome

# 난수를 생성하여 RSA 키 객체를 만들어 key 변수에 할당합니다.
ransdom_generator = Random.new().read
key = RSA.generate(1024, random_generator)

# 공개키를 만들고 암호화 합니다.
# encrypted는 튜플 객체를 반환하며 첫 번째 아이템에는 키 정보를, 두 번째 아이템은 항상 None을 반환합니다.
pub_key = key.publickkey()
encrypted = pub_key.encrypt(msg, 32) # 공개키로 암호화를 한다.
encrypted_msg = encrypted[0]

# 암호화 결과를 출력합니다.
print('==== encrypted message ====\\n{}\\n'.format(encrypted_msg))

# 복호화를 진행합니다.
decrypted_msg = key.decrypt(encrypted_msg) # 비밀키로 복호화 한다.

# 복호화 결과를 출력합니다.
print('==== decrypted message ====\\n{}'.format(decrypted_msg))

이론적으로 완벽한 암호화 시나리오 (대칭키+공개키)

대칭키를 주고 받을 때만 공개키 암호화 방식을 사용하고, 이후에는 계속 대칭키 암호화 방식으로 통신하는 것

A가 B의 공개키로 암호화 통신에 사용할 대칭키를 암호화하여 B에게 보낸다.
B는 암호문을 받아, 자신(B)의 비밀키로 복호화한다.
B는 A로 부터 얻은 대칭키로 A에게 보낼 평문을 암호화하여 A에게 보낸다.
A는 자신의 대칭키로 암호문을 복호화한다.
계속 대칭키로 암호화 통신을 한다.

사용하는 이유
- 공개키 방식이 많은 컴퓨터 파워를 사용하기 때문
- 만약 공개키를 그대로 사용하면 많은 접속이 몰리는 서버는 매우 큰 비용을 지불해야 할 것이다. 반대로 대칭키는 암호를 푸는 열쇠인 대칭키를 상대에게 전송해야 하는데, 암호화가 되지 않은 인터넷을 통해서 키를 전송하는 것은 위험하기 때문이다.
  - 그래서 속도는 느리지만 데이터를 안전하게 주고 받을 수 있는 공개키 방식으로 대칭키를 암호화하고, 실제 데이터를 주고 받을 때는 대칭키를 이용해서 데이터를 주고 받는 것이다.

https://prairie-swamp-444.notion.site/4-UDP-ecc5d2432c194a18ad77d7306625adcf

6. HTTP & HTTPS

HTTP

HTTP(Hyper Text Transfer Protocol)란 서버/클라이언트 모델을 따라 데이터를 주고 받기 위한 프로토콜이다.
- 즉 HTTP는 인터넷에서 하이퍼텍스트를 교환하기 위한 통신 규약으로, 80번 포트를 사용하고 있다. 따라서 HTTP 서버가 80번 포트에서 요청을 기다리고 있으며, 클라이언트는 80번 포트로 요청을 보내게 된다.
HTTP는 1989년 팀 버너스 리(Tim Berners Lee)에 의해 처음 설계되었으며, WWW(World-Wide-Web) 기반에서 세계적인 정보를 공유하는데 큰 역할을 하였다.

HTTP 동작

클라이언트(사용자)가 브라우저를 통해서 어떠한 서비스를 url을 통하거나 다른 것을 통해서 요청(request)을 하면 서버에서는 해당 요청사항에 맞는 결과를 찾아서 사용자에게 응답(response)하는 형태로 동작한다.
- 요청 : client -> server
- 응답 : server -> client

HTML 문서만이 HTTP 통신을 위한 유일한 정보 문서는 아니다.
Plain text로 부터 JSON 데이터 및 XML과 같은 형태의 정보도 주고 받을 수 있으며, 보통은 클라이언트가 어떤 정보를 HTML 형태로 받고 싶은지, JSON 형태로 받고 싶은지 명시해주는 경우가 많다.

HTTP 특징

HTTP 메시지는 HTTP 서버와 HTTP 클라이언트에 의해 해석이 된다.
TCP/ IP를 이용하는 응용 프로토콜이다.
- 컴퓨터와 컴퓨터간에 데이터를 전송 할 수 있도록 하는 장치로 인터넷이라는 거대한 통신망을 통해 원하는 정보(데이터)를 주고 받는 기능을 이용하는 응용 프로토콜
HTTP는 연결 상태를 유지하지 않는 비연결성 프로토콜이다.
- 이러한 단점을 해결하기 위해 Cookie와 Session이 등장하였다.
HTTP는 연결을 유지하지 않는 프로토콜이기 때문에 요청/응답 방식으로 동작한다.

예시로 알아보는 HTTP

서버 : 어떠한 자료에 대한 접근을 관리하는 네트워크 상의 시스템
- 요청에 대한 응답을 보내준다.
클라이언트 : 그 자료에 접근할 수 있는 프로그램
- Ex) 웹 브라우저, 핸드폰 어플리케이션 등...

클라이언트 프로그램에서 사용자가 회원가입을 시도하게 되면, 서버로 회원정보를 보내게 되고 서버는 회원 정보를 저장해주기도 한다. 이 과정에서 클라이언트와 서버 간의 교류가 HTTP라는 규약을 이용하여 발생하게 된다.

Request (요청)

클라이언트가 서버에게 연락하는 것을 요청이라고 하며 요청을 보낼때는 요청에 대한 정보를 담아 서버로 보낸다.

서버가 주문서를 받아 클라이언트가 어떤 것을 원하는지 파악할 수 있게 한다. 이처럼 요청은 식당에서 주문서를 작성하는 것과 같다고 생각하면 된다.

Request Method (요청의 종류)

GET : 자료를 요청할 때 사용
POST : 자료의 생성을 요청할 때 사용
PUT : 자료의 수정을 요청할 때 사용
DELETE : 자료의 삭제를 요청할 때 사용

Request HTTP 메시지 예시


GET <https://velog.io/@surim014> HTTP/1.1								// 시작줄
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) ...			  // 헤더
Upgrade-Insecure-Requests: 1

시작줄 (첫 줄)
- 첫 줄은 시작줄로 메서드 구조 버전으로 구성되었다.
  - GET : HTTP Method
  - https://velog.io/@surim014 : 사이트 주소
  - HTTP/1.1 : HTTP 버전

헤더 (두 번째 줄부터)
- 두번째 줄부터는 헤더이며 요청에 대한 정보를 담고 있다.
- User-Agent, Upgrade-Insecure-Requests 등이 헤더에 해당되며 헤더의 종류는 매우 많다.

본문 (헤더에서 한 줄 띄고)
- 본문은 요청을 할 때 함께 보낼 데이터를 담는 부분이다.
- 현재 예시에는 단순히 주소로만 요청을 보내고 있고 따로 데이터를 담아 보내지 않기 때문에 본문이 비어있다.

Response (응답)

서버가 요청에 대한 답변을 클라이언트에게 보내는 것을 응답이라고 한다.

Status Code (상태 코드)

상태 코드에는 굉장히 많은 종류가 있다. 모두 숫자 세 자리로 이루어져 있으며, 아래와 같이 크게 다섯 부류로 나눌 수 있다.

1XX (조건부 응답) : 요청을 받았으며 작업을 계속한다.
2XX (성공) : 클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 가리킨다.
3XX (리다이렉션 완료) : 클라이언트는 요청을 마치기 위해 추가 동작을 취해야 한다.
4XX (요청 오류) : 클라이언트에 오류가 있음을 나타낸다.
5XX (서버 오류) : 서버가 유효한 요청을 명백하게 수행하지 못했음을 나타낸다.

Resonse HTTP 메시지 예시

HTTP/1.1 200 OK														// 시작줄
Connection: keep-alive												 // 헤더
Content-Encoding: gzip
Content-Length: 35653
Content-Type: text/html;

<!DOCTYPE html><html lang="ko" data-reactroot=""><head><title...

시작줄 (첫 줄)
- 첫 줄은 버전 상태코드 상태메시지로 구성되어 있다. 200은 성공적인 요청이었다는 뜻이다.

헤더 (두 번째 줄부터)
- 두 번째 줄부터는 헤더로 응답에 대한 정보를 담고 있다.

본문 (헤더 뒤부터)
- 응답에는 대부분의 경우 본문이 있다.
  - 보통 데이터를 요청하고 응답 메시지에는 **요청한 데이터를 담아서 보내주기 때문이다.
  - 응답 메시지에 HTML이 담겨 있는데 이 HTML을 받아 브라우저가 화면에 렌더링한다.**

HTTPS

HyperText Transfer Protocol over Secure Socket Layer, HTTP over TLS, HTTP over SSL, HTTP Secure 등으로 불리는 HTTPS는 HTTP에 데이터 암호화가 추가된 프로토콜이다.
HTTPS는 HTTP와 다르게 443번 포트를 사용하며, 네트워크 상에서 중간에 제3자가 정보를 볼 수 없도록 공개키 암호화를 지원하고 있다.
HTTPS는 공개키/개인키 암호화 방식을 이용해 데이터를 암호화하고 있다. 공개키와 개인키는 서로를 위한 1쌍의 키이다.
- 공개키: 모두에게 공개가능한 키
- 개인키: 나만 가지고 알고 있어야 하는 키

공개키와 개인키로 암호화하면 다음과 같은 효과를 얻을 수 있다.

공개키 암호화: 공개키로 암호화를 하면 개인키로만 복호화할 수 있다.
-> 개인키는 나만 가지고 있으므로, 나만 볼 수 있다.

개인키 암호화: 개인키로 암호화하면 공개키로만 복호화할 수 있다.
-> 공개키는 모두에게 공개되어 있으므로, 내가 인증한 정보임을 알려 신뢰성을 보장할 수 있다.

HTTPS의 동작 과정

HTTPS는 SSL과 같은 프로토콜을 사용하여 공개키/개인키 기반으로 데이터를 암호화하고 있다.
- 데이터는 암호화되어 전송되기 때문에 임의의 사용자가 데이터를 조회하여도 원본의 데이터를 보는 것은 불가능하다.
서버는 클라이언트가 요청을 보낼 때 암호화를 하기 위한 공개키를 생성해야 하는데, 일반적으로는 인증된 기관(Certificate Authority) 에 공개키를 전송하여 인증서를 발급받고 있다. 자세한 과정은 다음과 같다.
1. A기업은 HTTP 기반의 애플리케이션에 HTTPS를 적용하기 위해 공개키/개인키를 발급
2. CA 기업에게 돈을 지불하고, 공개키를 저장하는 인증서의 발급을 요청함
3. CA 기업은 CA기업의 이름, 서버의 공개키, 서버의 정보 등을 기반으로 인증서를 생성하고, CA 기업의 개인키로 암호화하여 A기업에게 이를 제공함
4. A기업은 클라이언트에게 암호화된 인증서를 제공함
5. 브라우저는 CA기업의 공개키를 미리 다운받아 갖고 있어, 암호화된 인증서를 복호화함
6. 암호화된 인증서를 복호화하여 얻은 A기업의 공개키로 데이터를 암호화하여 요청을 전송함

호환된 인증서는 CA의 개인키로 암호화되었기 때문에, 신뢰성을 확보할 수 있고, 클라이언트는 A 기업의 공개키로 데이터를 암호화하였기 때문에 A기업만 복호화하여 원본의 데이터를 얻을 수 있다.

💨 HTTPS는 이러한 공개키/개인키 기반의 대칭키 암호화 방식을 활용하여 안전성을 확보하고 있다.

7. 로드 밸런싱(Load Balancing)

로드 밸런싱이란 둘 이상의 CPU나 저장장치 같은 컴퓨팅 자원들에 작업을 나누는 것이다.

로드 밸런싱을 하는 이유

웹 사이트에 접속하는 인원이 많아 이 사람들에 대한 모든 트래픽을 감당하기 위해
- 하드웨어의 성능을 높이거나 (Scale Up - 수직적 확장), 여러대의 서버가 나눠서 일하도록 만드는 (Scale out - 수평적 확장) 방법으로 해결
  - 하드웨어 성능 향상 비용이 훨씬 비싸고 더 불편하기 때문에 Scale out 방법을 주로 사용한다.

Scale out을 사용하면 서버가 여러대이기 때문에 무중단 서비스를 제공하는 환경 구성이 용이하고 이러한 서버들에게 균등하게 트래픽을 분산시켜주는 것이 로드 밸런싱이다.
로드 밸런싱은 분산식 웹 서비스로, 여러 서버에 부하(Load)를 나누어 주는 역할을 한다. Load Balancer를 클라이언트와 서버 사이에 두고, 부하가 일어나지 않도록 여러 서버에 분산시켜주는 방식이다.
- 서비스를 운영하는 사이트의 규모에 따라 웹 서버를 추가로 증설하면서 더 크고 많은 트래픽을 관리할 수 있게 된다.

로드 밸런서 서버 선택 방식

라운드 로빈(Round Robin) : CPU 스케줄링의 라운드 로빈 방식 활용
Least Connections : 연결 개수가 가장 적은 서버 선택
Source : 사용자 IP를 해싱하여 분배 (특정 사용자가 항상 같은 서버로 연결되는 것 보장)

로드 밸런서 장애 대비

서버를 분배하는 로드 밸런서에 문제가 생길 수 있기 때문에 로드 밸런서를 이중화하여 대비한다.

Active 상태와 Passive 상태
- 이중화를 하면 하나의 로드 밸런서가 장애가 생기면 다른 로드 밸런서가 잠시 일을 맡고 장애를 복구한 후 다시 교체해준다.

8. Blocking,Non-blocking & Synchronous,Asynchronous

Blocking VS Non Blocking

호출된 함수가 호출한 함수에게 제어권을 건네주는지 아닌지에 따라 나뉘게 된다. 함수 A와 B가 있을 때, A가 B를 호출한다고 가정하자.

Blocking : 호출된 함수에게 제어권을 건네준다.
- 함수 B를 호출하면서 제어권이 B에게 넘어가 B는 자기 할 일을 다 마칠때 까지 제어권을 갖고 있다. 따라서 A는 B가 끝날 때 까지 대기한다.
Non Blocking : 함수 B는 자신이 일이 다 끝나지 않아도 A에게 제어권을 바로 넘겨준다.
- 따라서 A는 B를 기다리면서 다른 일을 할 수 있다.

Synchronous VS Asynchronous

수행 중인 일의 동시성의 유무에 따라 나뉘게 된다. 위와 같이 A, B가 있을 때 B의 결과를 A가 신경쓰고 있는지 아닌지의 차이라고 보면 된다.

Synchronous : 함수 A는 함수 B가 일을 하는 중에 기다리면서, 현재 상태를 계속 체크한다.
Asynchronous : 함수 B의 수행 상태를 B혼자 신경쓰면서 처리한다. B가 끝나면 A에게 Callback 함수를 보내 끝났음을 알린다.

4가지 상황 예시

상황 : 치킨집에 직접 치킨을 사러감

1. Blocking & Synchronous

A : 사장님 치킨 한마리 포장해주세요!

B : 네 금방 되니깐 잠시만요!

A : 네!

B : ———치킨 튀기고 있음 ———

A : (아 언제 되지?.. 궁금한데 그냥 멀뚱히 서서 치킨 튀기는거 구경하면서 기다림)

즉 B가 치킨을 튀기고 있는동안 아무것도 하지 않고 기다리며 계속 감시한다.

2. Blocking & Asynchronous

A : 사장님 치킨 한마리 포장해주세요!

B : 네 금방 되니깐 잠시만요!

A : 네!

B : ———치킨 튀기고 있음 ———

A : (언제 다되는지 궁금하진 않지만, 잠시만 이라니깐 서서 기다림, 치킨 튀기는거 안봄)

즉 B가 치킨을 튀기고 있는동안 아무것도 하지 않지만 치킨 언제 다되는지 궁금하지도 않음

3. Non-Blocking & Synchronous

A : 사장님 치킨 한마리 포장해주세요!

B : 네~ 주문 밀려서 좀 걸리니깐 볼일 보시다 오세요!

A : 네!

B : ———치킨 튀기고 있음 ———

A :  (5분 뒤) 다 됐나요?

B : 아직이요

A :  (5분 뒤) 다 됐나요?

B : 아직이요

A :  (5분 뒤) 다 됐나요?

B : 아직이요

A :  (5분 뒤) 다 됐나요?

B : 네 여기요~

즉 B가 치킨을 튀기는 동안 다른 볼일을 보지만 계속 와서 다 됐는지 확인함

4. Non-Blocking & Asynchronous

A : 사장님 치킨 한마리 포장해주세요!

B : 네~ 주문 밀려서 좀 걸리니깐 볼일 보시다 오세요!

A : 네!

B : ———치킨 튀기고 있음 ———

A : (전화 하고 있음)

B : 치킨 나왔습니다~

A : 감사!

B 가 치킨을 튀기는 동안 관심 갖지 않고 그냥 딴짓함

요약

Blocking은 B가 뭐 하면 A가 뭐 못해!

Non Blocking은 B가 뭐 하고 있을 때 A 너 할거 하고 있어라

Synchronous는 참을성 없이 계속 다 됐는지 확인해

Asynchronous는 무관심하다 끝났다고 알려주면 가져가

9. Blocking & Non-Blocking I/O

I/O는 Kernel level에서만 수행 할 수 있다. 따라서 process, thread는 커널에게 I/O 작업을 요청해야한다.

Blocking I /O

Process(Thread)가 Kernel에게 I/O를 요청하는 함수를 호출한다.
Kernel이 작업을 완료할 때 까지 Wait 했다가 작업 결과를 반환 받으면 다시 작업을 수행한다.

I/O 작업은 CPU자원을 거의 쓰지 않기 때문에 Resource낭비가 심하다. Process가 중단되어 있기 때문에 이 시간동안 자원을 쓰지 않기 때문이다.

여러 클라이언트가 접속하는 서버를 Blocking으로 구현할 경우

I/O 작업을 진행하는 동안 작업을 중지한다.
다른 클라이언트가 진행중인 작업은 멈추면 안되기 때문에 Client 별로 별도로 스레드를 생성해야한다.
접속자 수가 많아지면 그만큼 많은 Thread가 생성될 것이고 이에 따라 컨텍스트 스위칭 횟수가 증가하게 된다.
컨텍스트 스위칭으로 오버헤드가 다량 발생하여 비효율적인 동작 방식이다.

Non Blocking I/O

User Process가 recvfrom 함수를 호출한다.

recvfrom : 커널에 해당 Socket으로부터 data를 받고 싶다고 요청하는 함수(주소를 지정하여 데이터를 받아오는 것)
Kernel은 이 요청에 대해 곧바로 recvBuffer을 채워 보낼 수 없기 때문에 "EWOULDBLOCK"을 return한다.
Blocking 방식과 달리 User Process는 다른 작업을 진행하고 있는다.
recvBuffer가 채워진 경우, Buffer로 부터 데이터를 복사해 받아온다.

recvBuffer은 Kernel이 가지고 있는 메모리에 적재되어 있어, Memory간 복사를 하기 때문에 I/O보다 훨씬 빠른 속도로 data를 받아온다.
recvfrom 함수는 빠른 속도로 data를 복사한 후 복사한 데이터의 길이와 함께 return한다.

아현

Studying Computer Science

이전 포스트

4. Operating System

다음 포스트

5. Network

Computer Science

1. OSI 7 계층

1) 물리(Physical) 계층

2) 데이터 링크(Data Link) 계층

3) 네트워크(Network) 계층

4) 전송(Transport) 계층

5) 세션(Session) 계층

6) 표현(Presentation) 계층

7) 응용(Application) 계층

2. TCP 3 way handshake & 4 way handshake

TCP의 특징

3 way handshake - 연결 성립

4 way handshake - 연결 해제

3. TCP/IP 흐름제어 & 혼잡제어

흐름 제어

ACK ?

흐름 제어

정지-대기(Stop-and-wait)

슬라이딩 윈도우(Sliding Window)

혼잡 제어

합 증가/곱 감소

슬로우 스타트(Slow Start)

혼잡 회피(Congestion Avoidance)

빠른 회복(Fast Recovery)

오류 제어

정지-대기 ARQ

Go-Back-n ARQ (GBn ARQ)

Selective-Reject(SR) ARQ

GBn ARQ 기법과 SR ARQ의 비교

4. UDP

TCP vs UDP

TCP (Transmission Control Protocol)

TCP의 특징

TCP Header 정보

ACK 제어비트

TCP의 연결 및 해제 과정

TCP Connection (3-way handshake)

TCP Disconnection (4-way handshake)

UPD Header 정보

DNS과 UDP 통신 프로토콜을 사용

5. 대칭키 & 공개키

대칭키 (Symmetric Key)

공개키

암호화 방식 진행 과정

이론적으로 완벽한 암호화 시나리오 (대칭키+공개키)

6. HTTP & HTTPS

HTTP

HTTP 동작

HTTP 특징

예시로 알아보는 HTTP

Request (요청)

Request Method (요청의 종류)

Response (응답)

Status Code (상태 코드)

HTTPS

HTTPS의 동작 과정

7. 로드 밸런싱(Load Balancing)

로드 밸런싱을 하는 이유

로드 밸런서 서버 선택 방식

로드 밸런서 장애 대비

8. Blocking,Non-blocking & Synchronous,Asynchronous

Blocking VS Non Blocking

Synchronous VS Asynchronous

4가지 상황 예시

상황 : 치킨집에 직접 치킨을 사러감

요약

9. Blocking & Non-Blocking I/O

Blocking I /O

여러 클라이언트가 접속하는 서버를 Blocking으로 구현할 경우

Non Blocking I/O

4. Operating System

6. Software Engineering

0개의 댓글