[네트워크] IP 주소, HTTP

서론

※ 아래 내용을 다룹니다.

• IP 주소 체계
• HTTP

 

https://github.com/SangBeom-Hahn/boost-interview

GitHub - SangBeom-Hahn/boost-interview: AI 엔지니어 기반을 다지는 공간

 

 

본론

- ARP

컴퓨터 간 네트워크 통신은 IP로 이루어진다고 알고 있지만, 사실은 컴퓨터 LAN 카드에 명시된 MAC 주소를 통해 이루어진다. ARP는 IP 주소로부터 MAC 주소를 알아내는 프로토콜이다. 인터넷 계층에 속하며 링크, 인터넷 계층을 통해 목적지 네트워크에 도달하면, ARP Requst를 브로드케스트하여 dst PC로 부터 ARP Apply 유니캐스트를 받아 MAC 주소를 알아낸다. 이는 매번 ARP를 사용하여 MAC을 찾지 않고, 한 번 찾은 MAC을 캐싱하여 성능을 향상시킬 수 있다.

 

브로드캐스트 : 해당 네트워크에 연결된 모든 호스트에게 신호를 보내는 것
유티캐스트 : 1대1 통신
IP 주소 : 아파트 동수로, 이동할 때마다 달라지는 가상 주소
MAC 주소 : 주민등록번호로, LAN 카드라는 주민등록카드에 한 번 정해진 주소는 절대 변하지 않는 실제 주소

 

- 홉바이홉 통신

IP 주소를 통해 통신하는 과정을 홉바이홉 통신이라고 한다. 통신은 목적 호스트에 도달하기 위해 수 많은 서버 네트워크의 라우트의 IP 테이블을 기반으로 패킷을 전달하고 또 전달하며 이동하는 것으로 중간 라우트를 징검 다리처럼 건너가는 모습을 의미한다. 시작점부터 목적지까지 메세지를 전달하는 것을 라우팅이라고 한다.

 

-> 라우팅 테이블

라우트에는 중간 목적지와 최종 목적지에 대한 IP 주소 정보가 있고 이를 테이블로 관리한다. 게이트웨이와 모든 목적지에 대해 최종 목적지에 도달하기 위해 거쳐야 할 다음 라우터 정보가 있다.

 

-> 게이트웨이

거쳐가는 네트워크에 들어가기 위한 관문으로 서로 다른 네트워크 상의 다른 프로토콜을 동일하게 맞춰주는 역할도 한다.

 

- IP 주소 체계

IPv4 : 32비트를 8비트씩 나눠 점으로 구분
IPv6 : 64비트를 16비트씩 나눠 점으로 구분

둘 다 IP 주소를 나타내는 방식이다.

 

-> IPv4 클래스 기반 할당 방식

IP 주소를 ABCDE 클래스로 구분하며, ABC는 통신용, DE는 예비용이다. ABC는 구분 비트를 통해 클래스마다 네트워크 주소 범위를 나타낸다.

 

A : 구분비트 0 -> 0.0.0.0 ~ 127.255.255.255
B : 구분비트 10 -> 128.0.0.0 ~ 191.255.255.255
C : 구분비트 110 -> 192.0.0.0 ~ 223.255.255.255

각 클래스는 네트워크 범위를 구분한다. A 클래스의 12.0.0.0은 네트워크 주소이고 12.0.0.1 ~ 12.255.255.254는 호스트 IP이다.

 

+ 정리

네트워크는 컴퓨터들이 연결된 망이라고 할 수 있고 해당 네트워크에 접속하기 위한 IP가 있고 네트워크들은 이 IP로 구분된다. 또한, 네트워크 내부 호스트에 접속하기 위한 IP가 있고 컴퓨터들은 각각의 IP를 가진다. 예를들어 보자

12.0.0.0 : 네트워크 IP로 13.0.0.0 네트워크와 구분된다.
12.0.0.1 ~ 12.255.255.254 : 네트워크 내부 호스트에 할당되는 IP
12.255.255.255 : 브로드캐스트용 IP

 

+ IPv4의 단점

네트워크 관리자가 수동으로 IP를 할당하고 관리하여 과거에 부여한 IP가 현재 사용되는 지 알 수 없고 사용하는 IP보다 버려지는 IP가 더 많아질 수 있다. 또한 호스트가 늘어나며 더 넓은 범위의 관리 체계가 필요하여 DHCP, IPv6, NAT가 나왔다.

 

- DHCP(동적 Host Configuration Protocol)

IPv4의 IP 관리가 어려운 문제를 해결하기 위해 나왔다. 라우터에 접속할 때마다 자동으로 IP를 할당하는 방식으로 관리자의 수동이 필요없고, IP 재사용에 용이하다. 라우터에 DHCP 기능이 있으며 대부분의 가정용 네트워크에서  IP 주소를 할당할 때 사용되며 인터넷에 접속할 때마다 IP 주소가 달라질 수 있다.

 

- NAT(Network Address Translation)

IPv4의 IP 부족 문제를 해결하기 위해 나왔다. 로컬 네트워크에서 하나의 공인 IP와 여러개의 사설 IP를 가지고 여러 호스트가 하나의 공인 IP로 인터넷에 접속할 수 있도록 한다. IP 주소록에는 공인 IP만 등록하고 내부에서 여러 개의 다른 IP 주소로 변환하여 IP 부족 문제에 상관없이 사용할 수 있다.

 

-> NAT의 역할

전송되고 있는 패킷의 IP 주소를 다른 IP로 수정한다. NAT 장치까지는 공인 IP 주소로 오고 NAT 장치에서 사설 IP로 패킷의 주소를 수정하여 목적 호스트에게 전달될 수 있도록 한다. 공유기에는 NAT 기능이 내장되어 있어 공유기에 접속한 호스트들은 네트워크 주소가 같은 사설 IP를 가진다. IP 주소록에 등록되는 것은 공인 IP 이므로 각각의 내부 네트워크의 사설 IP는 중복될 수 있고 로컬 네트워크에서만 유일하면 된다.

 

장점 : 외부 IP만 공개하여 보안이 가능함
단점 : 사설망에 접속하는 장치 수에 따라 트래픽이 몰려서, 속도가 느려질 수 있음

가정용으로 인터넷에 접속하면 공인 IP가 DHCP로 자동 할당되고 NAT 기능으로 사설 IP가 호스트에 할당될 것이다.

 

- HTTP(Hyper Text Transfer Protocol)

웹 브라우저에서 웹 사이트를 주고 받는 때 사용되는 프로토콜이다.

 

=> HTTP/1.0

하나의 연결에 한 번의 요청을 할 수 있는 프로토콜로, 매 요청마다 TCP 연결을 해야해서 요청하는 횟수도 증가하고 따라서, RTT도 증가한다.

 

-> RTT 증가 해결 방법

1) 이미지 스플릿팅

여러 개의 이미지를 다운로드 받으려면 여러 번의 요청을 해야하기 때문에, 여러 개의 이미지가 합쳐져있는 이미지를 한 번 다운로드하고 브라우저에서 여러 개로 전시하는 방법

 

웹에서 이미지 스플릿트란, 여러 개의 이미지를 하나의 이미지로 합쳐서 관리하는 것을 의미한다. 네이버에서 사용 중인 스프릿트 이미지 파일을 보면 하나로 주어지고 이를 브라우저에서 잘라서 여러 개로 사용하면 한 번의 요청으로 여러 장의 이미지를 사용할 수 있다. 하나의 사이트에 반드시 표기되어야 하는 이미지들이 있을 텐데 그것을 묶어서 관리하는 것이다.

 

2) 코드 압축

HTTP 메세지에서 띄어쓰기나 공백을 제거하는 등의 방식으로 압축하여 메세지의 용량을 줄여서 적은 대역폭에서도 보다 많은 요청과 응답이 가능하게 하며, 사용되는 메모리 감소 효과와 RTT 감소 효과를 가져올 수 있다.

 

3) 이미지 Base64 인코딩

이미지 파일을 64진법으로 이루어진 문자열로 인코딩하는 방식으로 서버와의 연결을 하지 않아도 이미지를 불러올 수 있다.

 

- HTTP/1.1

요청을 할 때마다 매번 TCP 연결을 하는 것은 비효율적으로, 지정한 timeout 동안 keep-alive 기능을 기본으로 제공하여 한 번의 연결에서 다수의 요청이 가능하다.

 

-> Pipe Lining

이전에는 하나의 연결에서 여러 개의 요청을 하더라도, 앞선 요청의 응답을 받아야 다음 요청을 할 수 있었다. 파이프라이닝 기능은 하나의 연결에서 여러 요청을 동시에 보낼 수 있는 기능이다.

 

-> 문제점

HOL BLocking : 동일한 네트워크 큐에서 전송되고 있는 패킷이 앞에 전송되고 있는 대용량 패킷에 영향을 받아, 전송이 지연되는 현상, 파이프라이닝을 사용하더라도, 응답이 요청 순서대로 진행됐기 때문에 앞 선 요청이 처리되기 전까지 다음 요청의 처리가 지연되는 현상이 발생했다.
무거운 헤더 : 헤더에 쿠키 등 다양한 정보로 인해 메세지의 용량이 커지고 메모리 자원 낭비 발생

 

🚨 HTTP/1.1이 해결한 것

하나의 연결에서 하나의 요청만 할 수 있는 것

 

- HTTP/2

HTTP/1.1까지 기본적인 기능이 추가되었고 2부터는 전송 지연, 속도 최적화와 같은 성능 개선에 초점을 맞췄다.

 

-> Binary Framing

기존 방식은 메세지를 문자열 기반으로 전송했지만, 더 작은 단위인 Binary 기반의 프레임 단위로 메세지를 전송한다. 이를 통해 멀티플랙싱과 같은 요청을 쪼개서 보내는 기능이 가능해졌다.

 

-> 멀티플랙싱

요청과 응답을 하나의 스트림에서 동작하도록 하는 방식으로, 하나의 연결에서 여러 개의 요청이 스트림 단위로 병렬적으로 동작한다. 스트림 간에 독립적이라서, 하나의 스트림에서 패킷 누락 등의 문제가 발생해도 다른 스트림에는 영향이 없고 하나의 연결에서 여러개의 스트림이 동시에 열리니 속도가 빠를 수 밖에 없다.

 

또한, 응답을 요청을 보낸 순서대로 하는 것이 아닌, 도착하는 순서대로 하여 HOL Blocking 문제를 해결한다. 스트림 내부도 Binary Frame 단위로 쪼개져있고 수신측에서 Frame 을 받아서 다시 조각해서 사용한다.

 

-> 헤더 압축

히프만 알고리즘을 적용하여 HPACK 단위의 헤더 형식으로 헤더 용량을 줄인다.

 

-> 서버 푸시

서버 푸시를 사용하지 않으면 웹 브라우저가 HTML을 요청할 때 이미지, CSS 파일마다 새로 서버에게 요청을 해야하고 이는 네트워크 IO, 파일 IO를 동반하는 비용이 발생한다. 서버 푸시를 사용하면 클라가 서버에 요청하지 않아도 서버가 미리 자원을 클라이언트에게 보낼 수 있다. 보낸 자원을 브라우저의 캐시에 저장할 수 있는데, 클라가 첫 번째 요청할 때 캐시에 저장해두고 두 번째 요청부터는 캐시로 부터 응답 받아 서버로 요청하지 않아도 된다.

 

- HTTPS

HTTP는 TCP 위에서 동작하는데 TCP와 HTTP 사이에 TLS 계층을 두어 전송 계층에서 데이터를 주고 받을 때 보안 세션을 생성하여 보안기능을 제공하는 HTTP를 말하고 이를 통해 통신을 암호화하여 보안 기능을 제공한다.

 

-> SSL/TLS(Secure Socket Layer, Transport Layer Security Protocol)

메세지를 주고 받기 전에 1RTT로 핸드쉐이크를 맺어서 보안 기능을 제공한다. 보안 세션을 생성할 때는 서버 CA 인증 메커니즘, 암호화 알고리즘이 사용된다. 즉, 보안 세션을 사용하여 인증된 사용자만 데이터를 주고 받을 수 있도록 보안을 활성화하는 것이고, 로그인 개념과는 전혀 다르며, 인증된 네트워크를 보장한다. 보안 세션을 생성한 후에는 암호화된 데이터를 전송한다.

 

-> 보안세션 : 

보안 기능이 활성화된 기간을 의미하며, 사용자끼리 인증과 인증 확인 절차를 거치고, 암호화된 데이터를 전송한다. 1RTT로 핸드쉐이크를 해서 보안을 생성한다.

 

-> 헨드쉐이크 원리 : 

클라와 서버가 인증, 인증 확인을 하는 1RTT를 한다.

 

1) 클라가 서버에게 사이퍼 슈트 전달
2) 서버는 사이퍼 슈트의 암호화 알고리즘 조회해서 제공할 수 있는 알고리즘인지 확인
3) 제공할 수 있는 알고리즘이라면 보안 세션 생성
4) 이후 데이터를 암호화하여 전송

 

-> 사이퍼 슈트 : 

1RTT때 클라가 서버에게 "서버가 제공할 수 있는 암호화 알고리즘이라면, 제공해줘"라는 의미로 전송하는 것으로 서버가 제공할 수 있는 사이퍼 슈트여야만 보안 세션이 생성된다. 프로코톨, AEAD 사이퍼 모드, 해싱 알고리즘 3개가 나열된 규약이고, 5가지 종류가 있다. 

 

-> AEAD 사이퍼 모드 : 

AES_128_GCM

암호화 알고리즘을 의미한다. 예를들어, AES 표준 알고리즘과 GCM 알고리즘이 결합된 암호화 알고리즘이다. 이것이 데이터 전송 시 데이터 암호화에 사용되는 것은 아니다.

 

-> 공인 서버 인증 메커니즘

자신의 서비스가 인증된 서비스라는 것은 인증하는 메커니즘으로 CA로부터 받은 인증서를 기반으로 인증하다. 인증서는 서버의 서비스 정보, 공개키 등의 내용이 담겨 있다. CA는 공인된 기업만 참여할 수 있고 아마존 등이 있다.

 

-> CA 발급 과정 : 

1) 서버가 CA에게 공개키와 서비스 정보를 제공
2) CA가 검토 후 공개키를 해싱하여 비밀키를 만들고 이를 CA 인증서로 제공

핸드세이크에서 클라가 서버에게 사이퍼 슈트를 전달하고 서버가 제공할 수 있는 암호화 알고리즘이라면, 보안 세션을 생성하는 인증 메커니즘을 제공한다고 했는데, 그 인증 메커니즘은 서버와 클라 사이의 인증 메커니즘이고 이는 공인된 서비스임을 인증하는 서버와 CA 간의 인증 메커니즘이다.

 

-> 키교환 암호화 알고리즘

디피헬만 기반의 DLE 방식을 사용하며, 클라와 서버가 키교환을 통해 서로를 인증하고 보안 세션을 생성한다. 이때 서버는 CA에게 발급받은 인증서를 클라에게 제공한다.

 

-> 해싱 알고리즘

SHA-256가 대표적이며, 이해할 수 있는 문자를 해싱하여 키 없이는 이해할 수 없는 암호로 매핑한다. 클라와 서버는 공유한 키를 통해 암호를 암호화하고 복호화한다.

 

해시 : 가변 길이의 문자 변환한 고정 길이의 문자값
해싱 : 가변 길이의 문자를 고정 길이의 문자로 변환하는 것. 파이썬의 HASH() 함수가 해싱을 제공

 

print(hash("hi"))

파이썬의 해시 함수를 출력해보면

 

이와 같이 암호화되어 나온다.

 

[깃헙 레포 / 깃헙 프로필 URL 성능 테스트]

검색 엔진의 검색 알고리즘에서 상단 노출 우선순위를 가지는 기준에는 HTTPS 설정 여부도 있으며, 그 외 캐노니컬 설정, 메타 설정, 페이지 속도 개선, 사이트맵 관리 등이 있다. TLS 최신 버전인 1.3에서는 사용자가 이전에 보안 세션을 생성한 사이트에 재방문할 경우 보안 세션을 유지하여 0 RTT로 보안을 제공한다.

 

-> HTTPS 구축 방법

1) 직접 자신의 서비스를 CA로부터 인증 받는 법
2) HTTPS를 제공하는 로드밸런서나 CDN을 서비스 앞단에 두는 법

 

- HTTP/3

TCP 위에서 동작하는 HTTP/2는 3-웨이 헨드쉐이크 때문에 초기 연결 지연이라는 문제가 있다. HTTP/3는 TCP 기반이 아닌 QUIC 계층 위에서 동작하며 UDP 기반으로 돌아간다.

 

-> QUIC(Quick UDP Internet Connections)

TCP를 사용하지 않기 때문에 3-WAY 핸드쉐이크 과정을 거치지 않고 1RTT로 첫 연결 설정이 되어 초기 연결 지연 시간이 제거되고 순방향 오류 수정 메커니즘으로 수신측에서 에러를 검출하고 수정하여 낮은 패킷 손실률을 자랑한다. QUIC 내에 TLS 인증서를 내포하고 있다.

 

🚨 각 버전마다 해결한 것

1) HTTPS : 클라이언트와 서버 간에 데이터를 주고 받을 때 보안 세션을 생성하여 인증된 사용자만 네트워크에 접속할 수 있도록 하고, 데이터 암호화 기능 제공
2) HTTP/3 : 초기 연결 설정 시간 감소
3) HTTP/2 : 문자열 기반 메세지를 Binary Frame 기반 메세지로 변경하여 멀티플랙싱과 같은 기능으로 HOL Blocking 문제 해결. + (지연 시간, 응담 시간 감소, 헤더 압축)
4) HTTP/1.1 : 하나의 연결에서 다수의 요청 가능

 

참고

[서버 푸시]