[Network] HTTP (1-3) - TCP 대신 UDP를 채택한 HTTP/3.0
HTTP/3.0 버전이 갖고 있는 특징과 장점, 그리고 우려되는 부분에 대한 설명 정리
HTTP/3.0의 이전 버전인 HTTP/2.0 버전에 대한 자세한 설명은 #HTTP (1-2) - HTTP/2.0은 무엇이 바뀌었는가? 게시글을 참고
HTTP/2.0 (TCP) → HTTP/3.0 (2019, UDP)
HTTP/2.0의 등장과 함께 기존의 프로토콜 데이터 체계를 프레임과 스트림 개념으로 재구축한 결과, 기존보다 혁신적으로 성능이 향상되게 되었다.
하지만 HTTP는 여전히 TCP 기반 위에서 동작되기 때문에 TCP 자체의 핸드쉐이크 과정에서 발생하는 지연 시간과, 기본적으로 TCP는 패킷이 유실되거나 오류가 있을 때 재전송을 하는데, 이 재전송하는 패킷에 지연이 발생하게 되면 결국 HOL(Head of Line) Blocking 현상이 발생하는 문제가 있었다.
즉, HTTP/2.0 버전은 #TCP/IP 4계층의 애플리케이션 계층(L4)에서 HTTP의 HOL Blocking 문제는 해결했지만, 전송 계층(L3)에서의 TCP 자체의 HOL Blocking 문제를 해결한 것은 아닌 것이다.
애초에 TCP ← 요놈으로 인터넷 통신을 하는 것 자체가 문제인 것이다.
점점 기술이 발전하고 다채로운 휴대 통신 기기가 널리 보급되면서 기업들은 다양한 컨텐츠를 여러 기기에 신속하게 전달하기 위해 TCP의 한계를 극복하고 최적화하는 것이 최대의 과제였다.
그래서 HTTP/2.0 버전의 기반이 된 SPDY 프로토콜을 개발한 구글에서 또 한번의 새로운 프로토콜 방식을 고안했다.
이 새로운 방식이 바로 UDP 기반인 QUIC 프로토콜로, 이 새로운 QUIC 프로토콜이 TCP/IP 4계층에도 동작시키기 위해 설계된 것이 바로 HTTP/3.0이다.
즉, HTTP/1.1과 HTTP/2.0은 TCP 기반이지만, HTTP/3.0은 UDP(QUIC) 기반이라고 보면 된다.
HTTP/3.0은 HTTP/2.0 버전이 갖고 있는 장점들은 모두 갖고 있으면서 TCP가 가지는 근본적인 단점을 보완하는 것을 중점으로 개발되었다.
그래서 지금까지 거론되었던 HTTP/2.0의 문제를 거의 해결했다고 봐도 무방하다.
RTT(Round Trip Time)를 거의 제로 수준으로 줄였으며, 패킷 손실에 대한 대응도 빠르고, 사용자의 IP가 바뀌어도 연결이 유지되는 것이 특징이다.
통신 인프라가 빈약한 나라에서는 큰 차이가 느껴질지도 모르겠지만, 사실 한국에서는 HTTP/2.0을 사용하든, HTTP/3.0을 사용하든 워낙에 땅이 좁고, 통신 인프라 자체가 전 세계에서 손꼽힐 정도로 잘 되어있기 때문에 소비자들은 체감을 못 할 것이다.
그렇지만 신기술은 쓰라고 있는 것, 당연히도 앞서가는 IT 기업들은 하나둘씩 HTTP/3.0을 도입하기 시작했다.
현재 Google, Naver, Netflix 등의 많은 사이트들이 지원하고 있으며,
2022년 11월에 한국 최초로 네이버에서 HTTP/3.0를 도입했다고 한다.
대부분의 메이저한 웹 브라우저 역시 지원하고 있다.
웹 브라우저 지원에 대한 내용은 Can I use…에서 확인할 수 있다.
또한 AWS와 같은 클라우드 서비스에서도 일부 서비스에 HTTP/3.0를 사용할 수 있는 옵션을 지원한다.
크롬 개발자 도구에서도 프로토콜 확인이 가능한데, 개발자 도구 → 네트워크 탭 → 우클릭 → 헤더 옵션 → 프로토콜 체크를 통해 HTTP 버전을 확인할 수 있다.
http/1.1은 보이는 그대로 HTTP/1.1 버전이고 h2는 HTTP/2.0, h3는 HTTP/3.0을 의미한다.
QUIC(Quick UDP Internet Connection) 프로토콜, 일명 퀵
HTTP/3.0의 가장 큰 특징은 기존의 HTTP/1.1, HTTP/2.0과는 다르게 UDP 기반의 프로토콜인 QUIC(Quick UDP Internet Connection)을 사용하여 통신하는 프로토콜이라는 점이다.
“Quick UDP Internet Connection”이라는 이름에서도 알 수 있듯이, 말 그대로 UDP를 사용하여 인터넷을 빠르게 연결하는 새로운 프로토콜이다.
참고로 “퀵”이라고 읽는다.
HTTP/2.0의 기반은 스피디, HTTP/3.0의 기반은 퀵
QUIC의 계층 위치
위의 #TCP/IP 4계층처럼 HTTP/3.0의 계층은 특이한 형태를 갖고 있다.
이런 특이한 형태인 이유는 QUIC은 TCP, TLS, HTTP의 기능을 모두 구현한 프로토콜이기 때문이다.
TCP의 프로토콜의 무결성 보장 알고리즘과 SSL이 이식됨으로써 높은 성능과 동시에 신뢰성을 충족시켰다고 보면 된다.
그래서 계층 위치도 약간 비스듬하게 걸쳐 있게 표현된 것이다.
다시 말하면, Application 계층의 HTTP/3.0은 QUIC를 동작시키기 위해 있는 것이다로 보면 되고, QUIC는 UDP 기반으로 만들어졌기에 Transport 계층의 UDP 위에서 동작한다고 보면 된다.
왜 TCP가 아닌 UDP를 채택했는가?
이유 1. TCP는 개선해도 여전히 느리다.
TCP가 만들어진 1970년대에는 아마 현재와 같이 클라이언트와 서버가 동시 다발적으로 여러 개의 파일의 데이터 패킷을 교환할 수 있게 될 것이라고는 상상도 못했을 것이다.
동시 다발적인 데이터 통신이 불가능했던 그 당시에는 무엇보다도 중요했던 것이 바로 데이터 통신의 안전성과 신뢰성이라고 생각했던 것 같다.
그래서 모바일 기기와 같은 네트워크 환경을 바꿔가면서 서버와 클라이언트가 소통할 수 있을 것이라고 생각하지 못했다.
그 때문에 와이파이를 바꾸면 다시 새로운 커넥션을 맺어야 되서 끊김 현상이 일어나는 것이다.
클라이언트 측에서 네트워크를 쉽게 바꿀 수가 없었기에 애초에 새로운 커넥션에 대한 고려 조차도 하지 않았을 것이다.
또한 TCP를 사용한 통신에서의 패킷은 신뢰성을 위해 무조건 순서대로 처리되어야 한다.
더군다나, 패킷이 처리되는 순서 또한 정해져있으므로 이전에 받은 패킷을 파싱하기 전까지는 다음 패킷을 처리할 수도 없다.
만일, 중간에 패킷이 손실되어 수신 측이 패킷을 제대로 받지 못했디면, 다시 보내야 한다.
이렇게 패킷이 중간에 유실되거나 수신 측의 패킷 파싱 속도가 느리다면 통신에 병목 현상이 발생하게 되는데, 이러한 현상을 HOL(Head of Line) Blocking라고 부른다.
이 HOL(Head of Line) Blocking 현상은 TCP 설계 상 어쩔 수 없이 발생하는 문제이기 때문에 HTTP/1.1 뿐만 아니라 HTTP/2.0도 가지고 있는 고질적인 문제였다.
이러한 고질적인 문제들을 해결하기 위해 HTTP/3.0는 결국 TCP와의 이별을 선언하고 UDP를 선택했다.
이유 2. UDP의 신뢰성은 커스터마이징하면 그만이다.
| TCP | UDP | |
|---|---|---|
| 연결 방식 | 연결 지향형 프로토콜 | 비연결 지향형 프로토콜 |
| 전송 순서 | 보장 | 보장하지 않음 |
| 신뢰성 | 높음 | 낮음 |
| 선송 속도 (상대적) | 느림 | 빠름 |
| 혼잡 제어 | ⭕️ | ❌ |
| 헤더 크기 | 20바이트 | 8바이트 |
UDP의 특징을 쉽게 정리하자면 하얀 도화지와 같이 기능이 거의 없어서 빠르지만 신뢰성이 낮으며, 중간 경로는 신경쓰지 않고 온전히 패킷을 목적지에만 전송하는 것을 목표로 하는 프로토콜이다.
| TCP | UDP |
|---|---|
 |  |
결국, UDP는 TCP가 신뢰성을 얻기 위해 내제된 과정을 거치지 않기 때문에 속도가 더 빠를 수 밖에 없다는 것인데, 그렇다면 UDP를 사용하게 되면 빠르지만 신뢰성과 패킷의 무결성을 보증할 수 없다는 뜻인데, 이것을 인터넷 통신에 사용해도 문제가 없는가?
여기서 오해가 생길 수 있는 부분이 바로 UDP는 빠르긴 하지만 신뢰성이 없기 때문에 사용성이 적다고 생각하는 부분인데, 사실 이는 명확하지 않다.
UDP의 헤더는 커스터마이징을 할 수 있는 공간이 많다는 것을 잊어서는 안된다.
즉, UDP는 신뢰성이 없는 것이 아닌, 탑재를 안했을 뿐이다.
위의 이미지와 같이 UDP 자체의 헤더는 비어있기 때문에 신뢰성도 낮고 제어 기능도 없지만, 개발자가 애플리케이션에서 구현을 어떻게 하냐에 따라서 TCP와 비슷한 수준으로 신뢰성이 높을 수도, 훌륭한 제어 기능을 가질 수도 있다는 말이다.
아예 새로운 프로토콜은 안되는가?
TCP가 문제이고 UDP도 애매하면 아예 다른 프로토콜을 만들거나 채택한다는 선택지도 있기는 하다.
이론적으로도 네트워크 스택에서 UDP와 TCP 옆에 새로운 전송 프로토콜을 만들 수 있다.
아니면 이미 있는 전송 프로토콜인 SCTP1를 사용할 수도 있다.
그러나 새 프로토콜 배포가 그리 쉬운 일이 아니다.
사용자와 서버 사이에 있는 TCP와 UDP만 허용하는 방화벽, #NAT, 라우터 등의 설정에 따라 차단될 수 있기 때문이다.
위와 같은 현상을 프로토콜 고착화(Ossification)라고 한다.
게다가 네트워크 스택의 전송 프로토콜 계층에서 뭔가를 바꾼다는 것은 새로운 운영 체제 커널을 갱신하고 프로토콜을 구현해 배포한다는 것인데, 이러한 배포 과정은 상당한 노력과 비용이 필요한 과정이다.
이러한 이유로 인해 이미 표준화된 수많은 TCP 개선 사항도 광범위하게 지원되지 않기 때문에 널리 배포되거나 사용되지 않고 있는 것이다.
#IPv6의 상용화가 왜 쉽지 않은지를 생각해보면 된다.
HTTP/3.0의 개선점
연결 Latency 감소
기존 TLS + TCP에서는 TLS 연결을 위한 핸드쉐이크와 TCP를 위한 핸드쉐이크가 각각 발생했다.
그래서 TCP는 연결을 생성하기 위해 기본적으로 1RTT가 필요하고, 여기에 TLS를 이용한 암호화 통신까지 한다면 총 3RTT가 필요하게 된다.
RTT (Round Trip Time)
RTT(Round Trip Time)란, 요청(
SYN)을 보낼 때부터 요청에 대한 응답(SYN-ACK)을 받을 때까지의 왕복 시간을 의미한다.
QUIC는 이를 한 단계로 줄였다.
UDP 위에서 동작하는 QUIC는 통신을 시작할 때 3-Way Handshake 과정을 거치지 않아도 되기 때문에, 첫 연결 설정에 대해서 1RTT만 소요된다.
그 이유는 연결 설정에 필요한 정보와 데이터를 함께 보내버리기 때문이다.
애초에 QUIC 내에 TLS 인증서를 내포하고 있기 때문에, 최초의 연결 설정에서 필요한 인증 정보와 데이터를 함께 전송한다.
그래서 클라이언트가 서버에 어떤 신호를 한 번 주고, 서버도 거기에 응답하기만 하면 바로 본 통신을 시작할 수 있는 것이다.
위에서 볼 수 있듯, TCP + TLS는 서로 자신의 세션 키를 주고 받아 암호화된 연결을 성립하는 과정을 거치고 나서야 세션 키와 함께 데이터를 교환하기 때문에, 핸드쉐이크 과정이 여러 번 발생한다.
하지만 QUIC은 서로의 세션 키를 교환하기도 전에 데이터를 교환할 수 있기 때문에 연결 설정이 더 빠르다.
다만, 최초의 요청을 보낼 때는 클라이언트는 서버의 세션 키를 모르는 상태이기 때문에, 목적지인 서버의 Connection ID를 사용하여 생성한 특별한 키인 초기화 키(Initial Key)를 사용하여 통신을 암호화한다.
그리고 한 번 연결에 성공했다면, 서버는 그 설정을 캐싱해놓고 있다가 다음 연결 때 캐시를 불러와서 바로 연결을 하기 때문에 추가적인 핸드쉐이크 없이 0RTT만으로 통신을 시작할 수 있다는 장점도 있다.
드디어 해결된 HOL Blocking
HTTP의 HOL Blocking
기존 HTTP/1.1 버전의 경우, 파이프라인(Pipeline) 기술을 통해 병렬적으로 리소스를 빠르게 얻도록 하려고 했지만, 첫 번째 요청에서 딜레이가 생긴다면 나머지 요청이 빨리 처리가 될 수 있음에도 불구하고 딜레이가 되는 치명적인 단점이 있었다.
위와 같이 b.png와 c.png가 아무리 빨리 처리되더라도 결과적으로는 a.png로 인해 늦게 받게 되는 것이다.
위와 같은 문제를 극복하기 위해 HTTP/2.0에서는 리소스들을 하나의 커넥션에서 병렬적으로 보내도록 개선했다.
a.png가 시간이 걸리더라도 b.png와 c.png는 먼저 받아서 보여줄 수 있게 된 것이다.
TCP의 HOL Blocking
앞서 설명했듯, HTTP 레이어의 HOL Blocking은 해결했지만, 문제는 TCP 레이어의 HOL Blocking 문제가 여전히 존재하고 있다는 것이다.
HTTP/2.0을 사용하는 일반적인 브라우저는 TCP 연결 한 개로 수십, 수백 개의 스트림 데이터를 병렬로 전송한다.
그런데 만약에 두 엔드포인트 사이에 네트워크 어딘가에서 하나의 패킷이 유실된다면?
유실된 패킷을 다시 전송하고 목적지를 찾는 동안 전체 TCP 연결이 중단되는 현상이 발생한다.
위처럼 HTTP/2.0에서 스트림에서 여러가지 프레임들이 뒤섞여 이동하게 되는데, 만일 어느 하나의 프레임에 문제가 생기면, 아무 상관없는 그 뒤의 프레임까지 영향을 미친다.
이렇게 되면 결국 HTTP의 HOL Blocking 현상처럼 스트림 내의 패킷들 전체가 지연되는 결과를 초래한다.
더군다나 HTTP/2.0은 1개의 TCP 커넥션으로 전부를 처리하고 있기 때문에, 패킷 손실률이 증가하면 여러 개의 TCP를 사용하는 HTTP/1.1보다 오히려 성능 저하가 더 커질 수 있다.
독립 스트림으로 HOL Blocking 단축
그래서 TCP를 버리고 새로운 QUIC 프로토콜을 구축해서 위와 같이 아예 스트림 자체를 독립적으로 여러 개로 나누어서 처리하도록 했으며, 이를 “독립 스트림”이라고 한다.
QUIC 연결을 통해 두 가지 다른 스트림을 설정했을 때, 이들을 독립적으로 다루므로 만약에 특정 스트림에서 HOL Blocking이 발생하더라도, 다른 스트림에는 영향을 미치지 않는다.
패킷 손실 감지에 걸리는 시간 단축
HOL Blocking 해결에 이어 QUIC은 흐름 제어하는 시간까지 단축했다.
QUIC도 TCP와 마찬가지로 전송하는 패킷에 대한 흐름 제어를 해야 한다.
QUIC는 기본적으로 TCP와 유사한 방법으로 패킷 손실을 탐지하지만, 여기에 몇 가지 알고리즘 개선 사항을 추가했다.
예를 들어, 위와 같이 HTTP/2.0에서는 하나의 스트림에 A, B, C 패킷 프레임들이 비순서대로 전달될 때, 만일 세 번째 프레임에서 패킷 손실이 일어난다면 패킷 B만 중지되어야 하지만, 전혀 연관없는 다른 패킷들도 모두 막혀서 대기를 해야 한다.
이러한 문제를 해결하기 위해 QUIC는 아래와 같이 헤더에 패킷의 전송 순서를 나타내는 별도의 패킷 번호 공간을 부여했다.
이를 통해 QUIC는 패킷 번호를 파악해 개별 파일을 구분하여 중간에 패킷 로스가 발생해도 해당 파일의 스트림만 정지되도록 할 수 있게 되었다.
하나의 스트림에서 문제가 발생한다고 해도 다른 스트림은 지킬 수 있게 되어 이런 문제에서 자유로워졌다.
더욱 향상된 Multiplexing
HTTP/3.0 역시 HTTP/2.0과 같은 멀티플렉싱을 지원하며, 위와 같이 독립 스트림 방식으로 기존의 멀티플렉싱을 더욱 강화시켰다고 보면 된다.
더욱 강화된 보안
HTTP/3.0과 그 기반 기술인 QUIC은 TLS 암호화를 기본적으로 사용한다.
물론 UDP와 TLS가 결합된 기술인 DTLS라는 기술도 존재하지만, “TCP의 재구현”이 목표 중 하나인 QUIC와는 지향하는 바가 다르다.
위와 같이 기본적으로 QUIC 내에 TLS가 포함되어 있기 때문에 TCP와 달리 헤더 영역도 같이 암호화된다.
네트워크가 변경되더라도 연결 유지
TCP의 경우 클라이언트와 서버가 서로를 구분하기 위해서는 클라이언트 IP, 클라이언트 PORT, 서버 IP, 서버 PORT 이렇게 네 가지가 필요하다.
그래서 클라이언트의 IP가 바뀌는 상황이 발생하면 연결이 끊어지게 된다.
쉽게 생각해서, 우리가 스마트폰으로 유튜브를 볼 때, Wifi로 영상을 보는 중에 4G 데이터를 사용하게 될 경우, 유튜브 영상이 살짝 끊기는 것과 같이 일시적인 지연이 일어나는 것이 클라이언트 IP가 이때 바뀌기 때문이다.
클라이언트 IP가 바뀌면서 다시 연결을 하기 위해 핸드쉐이크 과정을 다시 거쳐야 하는 것이고 이 과정에서 다시 지연 시간이 발생하는 것이다.
Connection ID
반면, QUIC은 Connection ID를 사용하여 서버와의 연결을 생성한다.
Connection ID의 각 연결은 연결 식별자나 연결 ID를 가지므로, 이를 통해서 연결을 식별한다.
Connection ID는 랜덤한 값일 뿐이며, 클라이언트의 IP와는 전혀 무관한 데이터이다.
그렇기에 클라이언트의 IP가 변경되더라도 기존의 연결을 계속 유지할 수 있게 되는 것이다.
그래서 새로 연결을 생성할 때 거쳐야하는 핸드쉐이크 과정을 생략할 수 있게 되고, 따라서 위의 실생활 예처럼 중간에 Wifi에서 4G로 변경해도 스트림이 계속 유지가 된다.
하지만 똑같은 Connection ID만 사용한다면 해커가 네트워크를 통해 사용자를 추적하여 보안 문제가 일어날 수도 있을 것이다.
그래서 QUIC은 새 네트워크가 사용될 때마다 Connection ID를 변경(?)한다.
위의 내용을 보면 갑자기 지금까지의 Connection ID 방식에 대한 설명에 정면으로 반박하는 내용처럼 보이지만, 내부적으로 클라이언트와 서버가 모두 연결을 위해 무작위로 생성한 Connection ID에 대해 인지하고 있고, 네트워크가 바뀔 때 Connection ID가 바뀌더라도 이 ID가 Connection ID와 동일하다고 인지하여 연결을 유지하는 것이다.
HTTP/3.0의 우려되는 점
HTTP/3.0과 QUIC 프로토콜의 기능으로만 따지면 좋은 기능들을 많이 제공해주고 있지만, 아직까지는 전 세계의 기업들이 이를 막상 도입하지 않는 현실적인 이유가 존재한다.
기존 체계 호환성 문제
프론트엔드단에서 HTTP/1.1이나 HTTP/2.0 기반으로 최적화를 이미 어느정도 해놓은 기업의 경우 QUIC 도입에 부담스러울 수 있다.
예를 들면, 브라우저의 병렬 다운로드를 통해 리소스를 빠르게 받아오는 도메인 분할(Domain Sharding) 기법을 이미 적용하여 최적화를 시킨 기업은 오히려 멀티플렉싱 기반의 HTTP/2.0 혹은 HTTP/3.0에서 성능이 반감될 수 있다.
또한 브라우저의 콘텐츠 Prefetch 기능을 적용한 경우, 이를 Server Push 기능으로 변경해야 할지에 대한 기술적인 판단과 충분한 성능 비교 테스트가 필요하게 된다.
암호화 관련 문제
암호화로 네트워크 제어가 어려움
QUIC의 경우, 기존에는 암호화하지 않던 헤더 필드도 암호화한다.
그래서 이런 헤더의 정보를 사용하는 ISP나 네트워크 중계 회사들은 기존에 암호화하지 않던 헤더 필드 영역들을 읽을 수 없어서 네트워크 혼잡을 관리하기 위한 네트워크를 최적화하기가 어렵다.
예를 들어 패킷이 ACK인지 재전송인지 알 수 없는 것이다.
RTT 추적은 더욱 어렵다.
이러한 이유로 기업들이 HTTP/3.0 도입을 주저하고 있다.
리소스가 많이 드는 암호화 과정
QUIC은 패킷 별로 암호화를 한다.
이는 기존의 TLS-TCP에서 패킷을 묶어서 암호화하는 것보다 더 큰 리소스 소모를 불러올 수 있다는 단점이 있다.
CPU를 너무 많이 사용하는 QUIC
QUIC은 CPU를 너무 많이 차지한다.
따라서 보급형 스마트폰과 IoT 장치같은 마이크로 애플리케이션들은 QUIC 이용에 어려움을 겪을 수 있다.
물론 시간이 지나면 개선될 수도 있지만, 추가적인 CPU 사용이 배포자에게 얼마나 영향을 끼치는지에 대한 것이 문제이다.
UDP의 보안적인 문제
DNS에서 TCP나 UDP는 53 포트를 이용해 통신하게 되는데, 53 포트가 아닌 UDP 트래픽이 최근에는 DoS 공격2에 주로 사용되기 때문에 많은 서비스들에서 차단하거나 속도를 제한하고 있다.
그래서 QUIC에서는 위의 문제를 해결하기 위해
- 초기 패킷이 최소 1,200바이트여야 한다.
- 서버가 클라이언트로부터 응답 패킷을 받지 않으면, 요청 크기의 3배 이상은 절대 보내서는 안된다.
위와 같은 프로토콜의 제약 사항을 설정하여 보안 문제를 해결하려고 노력 중이다.
기존에도 HTTP/2.0의 보안 관련된 여러 취약점이 발견되었고, 모든 업체가 이에 대한 보안 패치를 적용한 사례가 있듯, 새로운 기술이 나오면 보안 문제는 항상 나온다.
2022년 6월에 RFC 9114로 표준화되었는데, 게시글 작성 날짜 기준으로 고작 2년밖에 되지 않은 따끈따끈한 신기술인데 조금 기다려보자.
참고 사이트
드프 DrawingProcess - [Network] HTTP 버전 별 특징: HTTP v0.9 v1.0 v1.1 v2 v3
Semantics - HTTP (1) - version 별 특징 (0.9 / 1.0 / 2.0 / 3.0)
minu.log - HTTP/1.0, HTTP/1.1, HTTP/2.0, HTTP/3.0, and QUIC
스트림 제어 전송 프로토콜(Stream Control Transmission Protocol, SCTP)은 컴퓨터 네트워킹에서 프로토콜 번호 132를 사용하는 전송 계층 프로토콜의 하나로서, 잘 알려진 프로토콜인 전송 제어 프로토콜(TCP), 사용자 데이터그램 프로토콜(UDP)와 비슷한 역할을 수행한다. TCP처럼 연결지향적 프로토콜이며 혼잡 제어를 통해 신뢰성 있는 순차적 메시지 전송을 보장한다. ↩︎
서비스 거부(DoS) 공격은 사이버 공격의 한 유형으로, 장치의 정상적인 작동을 방해하여 컴퓨터 또는 기타 장치를 사용하려는 사용자가 해당 장치를 사용할 수 없게 만드는 것으로, DoS 공격은 일반적으로 정상적인 트래픽을 처리할 수 없을 때까지 대상 시스템을 요청으로 압도하거나 폭주시켜 추가 사용자에 대한 서비스 거부를 초래하는 방식으로 작동한다. ↩︎