[면접을 위한 CS 전공지식 노트] 네트워크

처리량(throughput) : 링크 내에서 성공적으로 전달된 데이터의 양, bps
지연시간(latency) : 요청이 처리되는 시간. 어떤 메시지가 두 장치 사이를 왕복하는데 걸린 시간
병목현상(bottleneck) : 전체 시스템의 성능이나 용량이 하나의 구성 요소로 인해 제한 받는 현상

네트워크 성능 분석 명령어

네트워크 병목 현상은 아래 원인들로 인해 유발될 수 있다.

• 네트워크 대역폭
• 네트워크 토폴로지
• 서버 CPU, 메모리 사용량
• 비효율적인 네트워크 구성

만일 네트워크와 관련된 테스트와 관련없는 테스트를 각각 진행한 뒤 문제점이 네트워크와 관련되어있다 라는 결론이 나왔다면 네트워크 성능 분석을 해야한다.

ping(Packet INternet Grouper)

ping [IP address or Domain address]

ping은 네트워크 상태를 확인하려는 대상 노드를 향해 일정 그기의 패킷을 전송하는 명령어이다. ping은 TCP/IP프로토콜 중 ICMP프로토콜을 통해 동작하기 때문에 ICMP 프로토콜을 지원하지 않는 기기 대상으로는 실행할 수 없다.

여러가지 옵션이 있는데 아래 명령어는 12번의 패킷을 보내라는 뜻이다. (교재에는 -n옵션을 주지만 맥북에서는 -c(count) 옵션을 주어야 한다.)

netstat

접속되어 있는 서비스들의 네트워크 상태를 표시하는데 사용된다. 주로 서비스의 포트가 열려있는지 확인할 때 쓴다.

nslookup

dns에 관련된 내용을 확인하기 위해 쓰는 명령어이다. 특정 도메인에 매핑된 IP를 확인할 때 사용한다.

tracert(traceroute)

목적지 노드까지 네트워크 경로를 확인할 때 사용하는 명령어이다.

TCP/IP 계층과 OSI 7계층

이 계층들은 특정 계층이 변경되어도 다른 계층이 영향을 받지 않도록 설계되었다.

이 책에서는 TCP/IP 계층을 기준으로 네트워크 계층에 대해 설명한다.

애플리케이션 계층

FTP, HTTP, SSH, SMTP, DNS 등 응용 프로그램이 사용되는 프로토콜 계층이다.

FTP	장치 간 파일 전송
HTTP	웹 사이트를 이용하는데 쓰는 프로토콜
SSH	보안되지 않은 네트워크에서 네트워크 서비스를 안전하기 운영하기 위한 암호화 프로토콜
SMTP	전자 메일 전송
DNS	도메인 이름과 IP주소를 매핑해주는 서버

전송 계층

TCP, UDP가 대표적이다.

송신자와 수신자를 연결하는 통신 서비스를 제공한다. 연결 지향 데이터 스트림 지원(?), 신뢰성, 흐름 제어를 담당한다. 또한 애플리케이션과 인터넷 계층 사이 데이터가 오고갈 때 중계 역할을 한다.

TCP는 패킷 사이의 순서를 보장하며 수신 여부를 확인한다. ‘가상회선 패킷 교환 방식’을 사용한다.

UDP는 순서를 보장하지 않고 수신 여부를 확인하지 않는다. ‘데이터그램 패킷 교환 방식’을 사용한다.

가상회선 패킷 교환 방식은 전송되는 패킷들의 이동 경로가 모두 같다. 그러나 데이터그램 패킷 교환 방식은 각 패킷들이 최적의 경로를 선택하여 이동하기 때문에 패킷들의 경로가 다를 수 있다. 따라서 패킷들의 도착 순서도 다를 수 있다.

앞서 TCP가 수신 여부를 확인한다고 작성하였는데 이 과정을 좀 더 자세히 알아보도록 하자. TCP는 데이터를 전송하기 전 3-way-handshake라는 작업을 진행한다.

1. 먼저 클라이언트는 서버에 클라이언트의 ISN(새로운 TCP 연결의 첫번째 패킷에 할당된 임의의 시퀀스 번호)를 담아 SYN을 보낸다.
2. 이후 서버는 클라이언트의 SYN을 수신하고 서버의 ISN을 보내며 승인 번호로 클라이언트의 ISN+1을 보낸다.
3. 클라이언트는 서버의 ISN+1한 값인 승인번호를 담아 ACK를 서버에 보낸다.

위 과정을 거치기 때문에 TCP는 신뢰성이 있다고 하며 UDP는 위 과정을 진행하지 않는다.

위 3-way-handshake과정을 거친 후 데이터 전송이 끝났다고 가정해보자. 그 다음에는 위에서 만든 연결을 해제해야하는데 이때는 4-way-handshake과정이 발생한다.

1. 클라이언트가 FIN으로 설정된 세그먼트를 보낸다. 이후 클라이언트는 FIN_WAIT_1상태로 들어가 서버의 응답을 기다린다.
2. 서버는 클라이언트로 ACK라는 승인 세그먼트를 보낸다. 이후 CLOSE_WAIT상태로 들어간다. 승인 세그먼트를 받은 클라이언트도 FIN_WAIT_2상태로 들어간다.
3. 서버는 ACK보낸 뒤 일정 시간 후 FIN이라는 세그먼트를 보낸다.
4. 클라이언트는 TIME_WAIT 상태가 되고 다시 서버로 ACK를 보내 서버는 CLOSED상태가 된다. 이후 클라이언트도 어느 정도의 시간을 대기한 뒤 연결이 닫힌다.

여기서 TIME_WAIT를 진행하는 이유는 아래와 같다.

1. 지연 패킷이 발생할 경우 대비
2. 두 장치가 연결이 닫혔는지 확인하기 위함

인터넷 계층

IP, APR, ICMP등이 있으며 장치로부터 받은 네트워크 패킷을 IP주소로 지정된 목적지로 전송하기 위해 사용된다. 상대방이 제대로 받았는지 보장하지 않는다.

링크 계층

전선, 광섬유, 무선 등으로 실질적으로 데이터를 전달하며 장치간에 신호를 주고받는 ‘규칙’을 정하는 계층이다.

그렇다면 이 계층간 데이터가 어떻게 이동하는지 보도록 하자. 상위 계층에서 하위 계층으로 이동하면서 헤더의 앞에 계속하여 해당 계층의 헤더가 삽입된다. 이를 반대로 하면 비캡슐화 과정이다.

아래와 같이 캡슐화→비캡슐화 과정을 거치며 비로소 장치간 데이터 전송이 완료된다.

이렇게 네트워크의 한 계층에서 다른 계층으로 데이터가 전달될 때 한 덩어리의 단위를 PDU(Protocol Data Unit)이라고 한다. PDU는 제어 관련 정보들이 포함된 ‘헤더’와 데이터를 의미하는 ‘페이로드’로 구성되어있으며 계층마다 부르는 명칭이 다르다.

PDU	OSI Model Layer
데이터	어플리케이션 계층
데이터	프레젠테이션 계층
데이터	세션 계층
세그먼트	전송 계층
패킷	네트워크 계층
프레임	데이터 링크 계층
비트	물리 계층

IP 주소

APR(Address Resolution Protocol)은 IP주소로부터 MAC 주소를 구하는 프로토콜이다. 반대로 MAC 주소로부터 IP주소를 변환하는 프로토콜은 RARP이다.

IP주소를 통해 통신하는 과정을 홉바이홉 통신이라고 한다. 통신망에서 데이터를 전달할 때 라우터의 라우팅 테이블 IP를 기반으로 패킷을 전달해가며 목적지로 나아간다.

라우팅 테이블 : 라우터에 들어가있는 목적지 정보들과 목적지로 가는 방법들이 들어있는 리스트. 라우터는 패킷을 받으면 라우팅 테이블 내에서 패킷의 목적지와 가장 일치하는 네트워크 주소를 검색
게이트웨이 : 서로 다른 통신망, 프로토콜을 사용하는 네트워크 간의 통신을 가능하게 하는 컴퓨터나 소프트웨어

IP 주소 체계(IPv4 & IPv6)

IPv4는 32비트를 8비트 단위로 점을 찍어 표기하고, IPv6는 64비트를 16비트 단위로 점을 찍어 표기한다.

초기에는 클래스단위로 네트워크를 할당하고, 그 중 네트워크의 첫 번째 주소는 네트워크 주소, 마지막 주소는 브로드캐스트용 주소로 활용되었다.

즉 클래스 A에 12.0.0.0이란 네트워크를 부여받았다면 첫 번째 주소인 12.0.0.0은 네트워크 구별 주소로, 12.255.255.255는 브로드캐스트용으로 남겨두어야 하니 12.0.0.1~12.255.255.254는 호스트 주소로 사용할 수 있는 것이다.

하지만 이 방법을 사용할 시 사용하는 주소보다 버리는 주소가 많게 되어, 이를 보완하기 위해 DHCP, IPv6, NAT가 등장하게 되었다.

DHCP(Dynamic Host Configuration Protocol)

IP주소 및 기타 통신 매개변수를 자동으로 할당하기 위한 네트워크 관리 프로토콜로, 네트워크 장치의 IP주소를 자동으로 할당할 수 있다.

NAT(Network Address Translation)

패킷이 라우팅 장치를 통해 전송되는 동안 패킷의 IP 주소 정보를 수정하여 IP 주소를 다른 주소로 매핑하는 방법이다. ICS, RRAS, Netfilter등의 소프트웨어로 NAT를 가능하게 할 수 있다. 아래 그림과 같이 하나의 IP를 기반으로 여러개의 IP를 가지는 것 처럼 사용할 수 있게 해주는 것이다.

NAT를 이용하면 내부 네트워크에서 사용하는 IP 주소와 외부에 드러나는 IP주소가 다르기 때문에 내부 네트워크에 대한 보안이 가능해진다는 장점이 있지만 실제 접속하는 호스트 숫자에 따라 속도가 느려질 수 있다는 단점이 있다.

HTTP

HTTP/1.0

초기 HTTP1.0은 한 연결당 하나의 요청을 처리하도록 설계되었다. 그러나 파일을 가져올 때 마다 앞서 봤던 TCP의 3-way-handshake를 계속해서 열어야했어서 RTT(패킷 왕복 시간)이 증가했다. 이를 해결하기 위해 이미지 스플리팅, 코드 압축, 이미지 Base64 인코딩 등이 사용되었다.

이미지 스플리팅 : 많은 이미지를 합친 하나의 이미지를 다운받고, 이를 기반으로 background-position을 이용해 이미지를 표기하는 방법

코드 압축 : 개행 문자, 빈칸 등을 없애 코드의 크기를 최소화 하여 코드의 용량을 줄이는 방법

이미지 Base64인코딩 : 이미지 파일을 64진법으로 이루어진 문자열로 인코딩하는 방법. 이미지에 대해 서버에 HTTP요청을 할 필요가 없지만 37%정도 크기가 더 커짐.
⇒ 원래 이미지를 HTTP요청을 통해 전송할 경우 클라이언트는 서버에게 이미지 파일의 URL을 제공하고 서버는 해당 URL로부터 이미지를 다운로드해 응답으로 전송한다. 하지만 이미지를 Base64로 인코딩하면 이미지 데이터를 문자열로 포함시킬 수 있어 별도의 HTTP요청을 할 필요가 없어지는 것이다.

HTTP/1.1

파일을 주고받을 때 마다 매번 TCP 연결을 하는 것이 아니라 한번 TCP초기화를 한 후 keep-alive옵션으로 여러개의 파일을 송수신할 수 있게 되었다.

이 HTTP/1.1에는 HOL Blocking(Head Of Line Blocking)이라는 문제점이 있었는데 네트워크에서 같은 큐에 있는 패킷이 첫 번째 패킷에 의해 지연될 때 발생하는 현상이다. 즉 아래와 같다.

<----------image.jpg---------->
                                <--style.css-->
                                               <----data.xml---->

image.png의 다운로드가 늦어진다면 뒤에 처리될 작업인 style.css와 data.xml의 다운로드도 함께 늦어지는 것이다. 또한 HTTP/1.1의 헤더에는 많은 메타데이터가 들어있고 압축이 되지 않아 무거웠다.

HTTP/2

새로 추가된 HTTP/2의 특징은 멀티플렉싱, 헤더 압축, 서버 푸시, 요청의 우선 순위 처리 지원 등이 있다.

멀티플렉싱은 여러개의 스트림을 사용하여 송수신 한다는 것이다. 즉 하나의 연결 내에서도 여러 개의 데이터를 각각 보내고 받을 수 있는 것이다. 예를들어 HTTP/1.1에서 파일 3개를 보내기 위해서는 3개의 TCP 연결이 필요했다. 그러나 HTTP/2에서는 하나의 TCP연결로 여러개의 스트림을 이용하여 3개의 파일을 주고받을 수 있다.

아래 링크에서 쉽게 설명한 애니메이션을 볼 수 있다.

HTTP 1.1 vs HTTP.2 vs HTTP/2 with Push - Manning

https://freecontent.manning.com/animation-http-1-1-vs-http-2-vs-http-2-with-push/?source=post_page-----565a7b184c--------------------------------

헤더 압축은 HTTP/1.1의 큰 헤더라는 문제점을 해결하기 위해 고안되었다. 허프만 코딩 압축 알고리즘을 이용해 헤더를 압축하는 것이다.

서버 푸시는 클라이언트의 요청 없이 서버가 바로 리소스를 푸시하는 것이다. 예를들어 html에는 css, js파일 등이 포함되는데 html을 읽으며 내부의 css, js파일을 클라이언트에 보내주는 것이다.

HTTPS

HTTP/2는 HTTPS위에서 동작한다. HTTP란 애플리케이션 계층과 전송 계층 사이에 신뢰 계층인 SSL/TLS 계층을 넣은 신뢰할 수 있는 HTTP요청을 말한다. 이를 통해 통신을 암호화 할 수 있다.

 

SSL(Secure Socket Layer)은 TLS(Transport Layr Security Protocol) 1.3까지 버전이 올라가며 TLS로 명칭이 변경되었으나 보통 SSL/TLS로 통칭한다.

 

SSL/TLS는 보안세션을 기반으로 데이터를 암호화하며 제3자가 서버인 척 하며 사용자 정보를 가로채는 것(인터셉터)을 방지할 수 있다.

보안세션은 보안이 시작되고 끝나는 동안 유지되는 세션을 말한다. 클라이언트와 서버가 키를 공유하고 인증, 인증 확인 등의 작업이 일어난 뒤 해싱알고리즘으로 암호화된 데이터의 송수신이 시작된다.

 

인증 확인을 위해 클라이언트와 서버는 각각의 개인키와 공개키를 생성하고 서로에게 공개키를 보내 공개키와 개인키를 결합한다. 이 값은 디피-헬만 키 교환 암호화 알고리즘을 따르기 때문에 같은 값이 생성된다. 이를 통해 키를 암호화 할 수 있다.

HTTP/3

HTTP/3은 HTTP/2와 달라 QUIC이라는 계층 위에서 돌아가며 UDP기반이다. QUIC은 TCP를 사용하지 않기 때문에 3-way-handshake과정을 거치치 않아도 된다. QUIC을 이용한 HTTPS는 첫 연결에 1-RTT만 소요된다. 또한 순방향 오류 수정 메커니즘이 적용되어 있기 때문에 열악한 네트워크 환경에서도 낮은 패킷 손실률을 보장한다.

📚Reference

https://mabb.tistory.com/530

[개발관련] 이미지를 base64로 인코딩할 경우 HTTP 요청을 할 필요가 없는 이유_chatGPT

https://ifuwanna.tistory.com/72

Base64 인코딩 (Base64 인코딩 이유)

https://velog.io/@uoayop/HTTP