HTTPS 와 DNS 그리고 UDP#3

이전 http 프로토콜 내용을 다룰 때도 한번 언급되었던 개념이었던 https
이번 게시글의 메인 주제이다.
그럼 http와 항상 함께 언급되는 https에 대해서 알아보자.

HTTPS VS HTTP

• HTTPS URL은 "https://" 로 시작, 기본 포트번호는 443
• HTTP URL은 "http://" 로 시작, 기본 포트번호는 80
• HTTP는 평문 데이터를 기반으로 하기 때문에, 유저정보와 같은 민감한 정보가 인터넷 상에 그대로 노출됨, 이 정보는 수집되거나 변조될 수 있음
• HTTPS는 이러한 공격을 견딜 수 있도록 설계돼 있음
• HTTPS는 인증서를 이용해서, 접속 사이트를 신뢰할 수 있는지 평가할 수 있음
• 일반적으로 HTTPS는 HTTP에 비해서 (매우 많이)느림
• 많은 양의 데이터를 처리할 경우 성능의 차이를 체감할 수 있음
• 많은 웹 사이트들이 민감한 정보를 다루는 페이지 (로그인 혹은 유저정보) 페이지를 HTTPS로 전송하고, 기타 페이지는 HTTP로 전송하는 방법을 사용

HTTPS와 SSL

• SSL(Secure Socket Layer)은 전자상거래에서의 데이터 보안을 위해서 개발한 통신 레이어
• SSL은 표현 계층의 프로토콜로 응용 계층 아래에 있기 때문에, 어떤 응용 계층의 데이터라도 암호화해서 보낼 수 있음
• HTTPS에서 마지막의 S는 Over Secure ockSet Layer의 약자로 Secure라는 말을 통해서 알 수 있듯이
  보안이 강화된 HTTP 라는 것을 짐작할 수 있음
• HTTP는 기본적으로 평문 데이터 전송을 원칙으로 하기 때문에 개인의 프라이버시가 오가는 서비스들(전자상거래, 전자메일, 사내문서)에 사용하기 힘듬
• HTTPS는 SSL위에 HTTP를 통과 시키는 방식. 즉, 평문의 HTTP 문서는 SSL 레이어를 통과하면서 암호화 돼서 목적지에 도착하고, 목적지에서는 SSL 레이어를 통과하면서 복호화 돼서 웹 브라우저에 전달됨
• 간혹 SSL과 HTTPS를 하나의 프로토콜로 인식하기도 하는데, HTTP와 SSL은 전혀 다른 계층의 프로토콜콜의 조합임
  HTTPS도 SSL 프로토콜 위에서 돌아가는 프로토콜 (HTTPS over SSL)로 보는게 좀더 정확한 시각

SSL과 TLS

SSL

원래 웹에서의 데이터는 가로채면 누구나 읽을 수 있는 일반 텍스트 형태로 전송 되어 보안 문제가 있었다.
이러한 문제때문에 인터넷 통신의 개인정보 보호, 인증, 데이터 무결성을 보장하기 위해
Netscape가 1995년 처음으로 SSL을 개발하였다.

• SSL(Secure Scokets Layer)은 암호화 기반 인터넷 보안 프로토콜
• 암호화를 사용하여 데이터의 무결성과 기밀성을 보호
• 전달되는 모든 데이터를 암호화하고 특정한 유형의 사이버 공격도 차단
• SSL은 TLS(Transport Layer Security) 암호화의 전신
• SSl/TLS 를 사용하는 웹사이트 URL은 HTTP 대신 HTTPS가 사용됨
• SSL은 1996년 SSL 3.0 이후 업데이트되지 않았으며, 앞으로 사라지게 될 것으로 여기지고 있음.
  또한 알려진 취약성이 여러가지 있으며 보안 전문가들은 SSL 사용 중단을 권장. 그 대안으로는 앞에서 언급한 TLS가 있음

TLS

• TLS(Transfer Layer Security)는 암호화 및 인증을 지원하는 최신 암호화 프로토콜로,
  SSL 암호화로 혼용해서 부르는 경우도 많음
• TLS는 SSL의 업데이트 버전으로 SSL의 최종버전인 3.0과 TLS의 최초버전의 차이는 크지않으며,
  이름이 바뀐 것은 SSL을 개발한 Netscape가 업데이트에 참여하지 않게 되어 소유권 변경을 위해서였음
• 결과적으로 TLS는 SSL의 업데이트 버전이며 명칭만 다르다고 볼 수 있음

SSL/TLS 인증서가 필요한 이유는?

• SSL/TLS 인증서는 웹사이트와 사용자 간에 전송되는 데이터를 암호화함
• 전송하는 모든 정보는 안전하게 보호되며 다른 사람이 볼 수 없음
  -> 이는 신용카드 번호, 비밀번호 및 기타 데이터와 같은 민감한 정보를 보호하는 데 필수적
• SSL/TLS 인증서가 없으면 웹사이트와 동일한 네트워크에 있는 모든 사람이 서버와 사용자의 웹 브라우저 간의 트래픽을 가로챌 수 있음
  -> 교환되는 모든 정보를 볼 수 있으며 심지어 정보를 전송하기 전에 정보를 변경할 수도 있음

SSL과 TLS 차이점

SSL	TLS
SSL은 보안 소켓 계층의 약자	TLS는 전송 계층 보안의 약자
넷스케이프는 1995년에 SSL을 개발	인터넷 엔지니어링 태스크포스(IETF)는 1999년에 처음으로 TLS를 개발
세가지 버전 SSL 1.0 SSL 2.0 SSL 3.0	네가지 버전 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3
모든 버전의 SSL에서 취약점이 발견되어 모두 사용 중단	2020년 3월부터 TLS 1.0 및 1.1은 더 이상 지원되지 않음 대부분의 경우 TLS 1.2 사용 TLS가 SSL을 대체

메시지 인증

SSL과 TLS의 주요 차이점은 메시지 인증입니다.

• SSL은 메시지 인증 코드(MAC)를 사용하여 전송 중에 메시지가 변조되지 않도록 함
• TLS는 보호를 위해 MAC을 사용하지 않고 대신 암호화와 같은 다른 수단을 사용하여 변조를 방지

기록 프로토콜

레코드 프로토콜은 TLS와 SSL 모두에서 보안 통신 채널을 통해 데이터를 전송하는 방식이지만, 몇 가지 사소한 차이점이 있습니다.

• TLS에서는 패킷당 하나의 레코드만 가져올 수 있는 반면, SSL에서는 패킷당 여러 개의 레코드가 전송될 수 있음(거의 구현되지 않았지만)
• 또한 압축 및 패딩 옵션과 같은 TLS의 레코드 프로토콜의 일부 기능은 SSL에 포함되어 있지 않음

사이퍼 스위트(Cipher Suite)

• TLS는 암호화 및 암호 해독에 사용되는 알고리즘인 다양한 암호 제품군을 지원
  가장 잘 알려진 암호 집합은 타원 곡선을 기반으로 하는 임시 DHE(Diffie-Hellman) 키 교환으로,
  완벽한 순방향 비밀성(PFS)을 제공하며 모든 키 길이에 사용할 수 있음.
  다른 몇 가지 암호 제품군도 PFS를 지원하지만 널리 사용되지는 않음
• SSL은 1024비트 RSA 키를 사용하는 PFS를 사용하는 하나의 암호 제품군만 지원함

알림 메시지

• SSL 프로토콜은 경고 메시지를 사용하여 통신 중 특정 오류에 대해 클라이언트 또는 서버에 알림
• TLS 프로토콜에는 이와 동등한 메커니즘이 없음

HTTPS 암호화 과정

SSL/TLS 의 작동 방식

• SSL은 개인정보 보호를 제공하기 위해, 웹에서 전송되는 데이터를 암호화 함 -> 데이터를 가로채려해도 거의 복호화가 불가능
• SSL은 클라이언트와 서버간에 핸드셰이크를 통해 인증이 이루어짐
• 또한 데이터 무결성을 위해 데이터에 디지털 서명을 하여 데이터가 의도적으로 도착하기 전에 조작된 여부를 확인

SSL 인증서와 SSL 핸드셰이크에 탑재된 기술

SSL 인증서 관련 프로세스에는 아래와 같은 보안 기술이 탑재되어 있음

• 대칭키 암호화 방식
• 비대칭키 암호화 방식
• 통신 대상을 서로가 확인하는 신분 확인
• 믿을 수 있는 SSL 인증서를 위한 디지털 서명
• 디지털 서명을 해주는 인증 기관 확인
• 공개키를 안전하게 전달하고 공유하기 위한 프로토콜
• 암호화된 메시지의 변조 여부를 확인하는 메시지 무결성 알고리즘

SSL 핸드셰이크 (SSL/TLS Handshake) 과정

• 핸드셰이크(Handshake)란 악수를 의미, 브라우저와 웹 서버가 서로 암호화 통신을 시작할 수 있도록 신분을 확인하고, 필요한 정보를 클라이언트와 서버가 주고받는 과정이 악수와 비슷하여 붙여진 이름
• 핸드셰이크(Handshake)는 클라이언트와 서버간의 메세지 교환이며, HTTPS 웹에 처음 커넥션할 때 진행
• 핸드셰이크의 단계는 클라이언트와 서버에서 지원하는 암호화 알고리즘, 키 교환 알고리즘에 따라 달라짐
• 일반적으로는 RSA 키 교환 알고리즘이 사용

클라이언트: ① 클라이언트에 해당하는 브라우저가 먼저 웹 서버에 접속 (Client Hello)
웹 사이트 접속에 HTTPS를 사용하는 브라우저는 다음 정보를 Client Hello 단계에서 보냄

• 브라우저가 사용하는 SSL 혹은 TLS 버전 정보
• 브라우저가 지원하는 암호화 방식 모음(cipher suite)
• 브라우저가 순간적으로 생성한 임의의 난수(숫자)
• 만약 이전에 SSL 핸드셰이크가 완료된 상태라면, 그때 생성된 세션 아이디(Session ID)
• 기타 정보

cipher suite는 보안의 궁극적 목표를 달성하기 위해 사용하는 방식을 패키지 형태로 묶어 놓은 것을 의미. 여기서 보안의 목표는 다음과 같음

• 안전한 키 교환
• 전달 대상 인증
• 암호화 알고리즘
• 메시지 무결성 확인 알고리즘

서버: ② 웹 서버는 ① 번에 응답하면서 아래 정보를 클라이언트에 제공 (Server Hello)

• 브라우저의 암호화 방식 정보 중에서 서버가 지원하고 선택한 암호화 방식(cipher suite)
• 서버의 공개키가 담긴 SSL 인증서. 인증서는 CA 비밀키로 암호화되어 발급된 상태
• 서버가 순간적으로 생성한 임의의 난수(숫자)
• 클라이언트 인증서 요청(선택사항)

클라이언트: ③ 브라우저는 서버의 SSL 인증서가 올바른지 확인

• 대부분의 브라우저에는 공신력 있는 CA 들의 정보와 CA가 만든 공개키가 이미 설치되어 있음
• 서버가 보낸 SSL 인증서가 정말 CA가 만든 것인지를 확인하기 위해, 내장된 CA 공개키로 암호화된 인증서를 복호화함
• 정상적으로 복호화되었다면 CA가 발급한 것이 증명되는 셈
• 만약 등록된 CA가 아니거나, 등록된 CA가 만든 인증서처럼 꾸몄다면 이 과정에서 발각이 되며 브라우저 경고를 보냄

클라이언트: ④ 브라우저는 자신이 생성한 난수를 사용하여 premaster sercret을 만듦

• 웹 서버 인증서에 딸려 온 웹 사이트의 공개키로 이것을 암호화하여 서버로 전송

서버: ⑤ 서버는 사이트의 비밀키로, 브라우저가 보낸 premaster secret 값을 복호화함

• 복호화 한 값을 master secret 값으로 저장
• 이것을 사용하여 방금 브라우저와 만들어진 연결에 고유한 값을 부여하기 위한 세션키를 생성
• 세션키는 대칭키 암호화에 사용할 키
• 이것으로 브라우저와 서버 사이에 주고받는 데이터를 암호화하고 복호화함

서버/클라이언트: ⑥ SSL 핸드셰이크를 종료하고 HTTPS 통신을 시작

• 브라우저와 서버는 SSL 핸드셰이크가 정상적으로 완료
• 이제는 웹상에서 데이터를 세션키를 사용해 암호화/복호화하며, HTTPS 프로토콜을 통해 주고받을 수 있음
• HTTPS 통신이 완료되는 시점에서 서로에게 공유된 세션키를 폐기
• 만약 세션이 여전히 유지되고 있다면 브라우저는 SSL 핸드셰이크 요청이 아닌 세션 ID만 서버에 알려주면 됨

• SSL 핸드셰이크 과정은 구현체마다 조금씩 다른 옵션을 가지고 있지만, 대부분의 원리는 위의 내용에서 크게 벗어나지 않음
• SSL 인증서에는 대칭키 방식과 공개키 방식 두 가지 방식 모두 사용하며, 모든 웹 콘텐츠의 전달을 공개키 방식으로 한다면 웹 서버와 브라우저에 많음 부담이 됨
• 그래서 SSL 핸드셰이크 단계까지는 공개키 방식, 그 이후의 HTTPS 통신은 대칭키 방식 사용

대칭 키와 비대칭 키(공개키)

대칭키 암호화 방식

• 대칭키 암호화 방식이란 하나의 암호화키(key)로 평문을 암호화하고, 다시 암호문을 원해의 평문으로 복호화할 때 사용하는 방식
• 키를 단 하나만 사용하는 간편함이 있지만, 키를 분실하거나 도난을 당한다면 내 암호문을 누군가가 복호화하여 볼 수 있다는 치명적 단점이 있음

공개키 암호화 방식

• 공개키 암호화 방식은 공개키, 개인키 이렇게 두 개의 키를 한 쌍(키페어: key pair)으로 각각 암호화/복호화에 사용
• 일반적으로 공개키로 암호화 한 것을 개인키로 복호화 함
• 개인키를 먼저 만들고, 여기서 공개키를 파생하여 한 쌍의 키를 만들기 때문에 키페어라 부름
• 만약 같은 쌍이 아닌 다른 키를 사용하려 한다면 암호화/복호화 불가능

HTTPS를 적용하면 100% 안전할까?

HTTPS는 웹에서 보안을 적용하기 위한 가장 기본적 단계이고, 이것으로 모든 보안성이 완벽하게 지켜졌다고 할 수 없음.
인스턴트 메시징 서비스와 같이 개인 간 혹은 그룹 간 대화, 민간한 개인 정보 등의 전달에서는 HTTPS를 적용하면서도, 종단 간 암호화 기술을 추가로 적용하여 HTTPS가 무력화되어도 노출된 데이터는 암호화를 유지해, 외부로 노출되지 않도록 하는 방법을 일반적으로 사용

DNS란?

• DNS(Domain Name System)는 인터넷 전화번호부
• 사람은 gmail.com 또는 naver.com과 같은 도메인 이름을 통해 온라인으로 정보에 액세스함
• 웹 브라우저는 인터넷 프로토콜(IP) 주소를 통해 상호작용 함
• DNS는 브라우저가 인터넷 자원을 로드할 수 있도록 도메인 이름을 IP 주소로 변환
• 상위 기관에서 인증된 기관에게 도메인을 생성하거나 IP 주소로 변경할 수 있는 '권한'을 부여
• DNS는 이처럼 상위 기관과 하위 기관과 같은 계층 구조를 가지는 분산 데이터베이스 구조를 가짐

DNS 서버가 중요한 이유

• DNS 서버가 없다면 사용자는 방문하려는 모든 웹사이트에 대해 복잡한 숫자 IP 주소를 기억해야 하므로
  인터넷이 훨씬 덜 사용자 친화적이 될 것임
• 대신 DNS 서버는 보이지 않는 곳에서 번역을 처리하여 사용자가 웹에 쉽게 액세스할 수 있도록 도움
• DNS 서버는 도메인 이름과 해당 IP 주소의 데이터베이스를 유지 관리함
• 사용자가 웹사이트에 대한 액세스를 요청하면 DNS 서버는 도메인 이름과 연결된 IP 주소를 조회하여 사용자의 디바이스를 올바른 위치로 안내함

DNS 작동 방식

1. 웹 브라우저에 도메인 이름을 입력하면 컴퓨터는 해당 IP 주소를 얻기 위해 DNS 서버에 요청을 보냄

2. 요청을 받은 DNS 서버는 데이터베이스를 검색하거나 다른 DNS 서버에 연결하여 도메인 이름과 연결된 IP 주소를 탐색

3. IP 주소를 찾으면 컴퓨터로 반환되어 요청된 웹사이트 또는 서비스에 연결할 수 있음

   FQDN(Fully Qualified Domain Name) 전체 도메인 이름
   도메인의 전체 이름을 표기하는 방식

DNS 질의 종류 및 서버 종류

재귀적 질의(Recursive Query)

• 시용자 호스트가 Recursive 네임서버(Name Server = DNS Server)로 질의할 때 사용되는 방식
• Recursive 네임서버로 대상 도메인의 리소스 레코드 정보를 조회하여 응답해 달라는 질의를 의미
• Recursive 네임서버는 자신의 캐시 데이터를 조회한 후 데이터가 있으면 사용자 호스트로 그 결과를 반환하고,
  데이터가 없으면 최상위 Root 네임서버부터 질의 대상 도메인 네임서버까지 반복적 질의를 수행한 후 그 결과를 사용자 호스트에 반환함

반복적 질의(Iterative Query)

• Recursive 네임서버가 도메인을 관리하는 각 네임서버로 질의할 때 사용하는 방식
• 최상위 Root 네임서버부터 계층구조에 따라 대상 도메인 네임서버까지 각 네임서버가 응답하는 위임된 네임서버 정보에 따라
  순차적으로 반복하여 진행하는 질의를 의미함

루트 DNS 서버

• ICANN(국제인터넷주소관리기구)이 직접 관리하는 서버
• TLD DNS 서버 IP 주소를 저장하고 안내하는 역할함

TLD(Top-Level Domain) DNS 서버

• 도메인 등록 기관(Registry)이 관리하는 서버
• Authoritative DNS 서버의 주소를 저장하고 안내하는 역할함
• 도메인 판매 업체(가비아 등)의 DNS 설정이 변경되면 도메인 등록 기관으로 전달되기 때문에 어떤 도메인이 어떤 판매업체(가바이 등)에서 구매했는지 알수 있는 것

SLD(Second-Level Domain) DNS 서버

• Authoritative DNS 서버 라고도 함
• 실제 개인 도메인과 IP 주소의 관계가 기록(저장, 변경)되는 서버
• 그래서 권한의 의미인 Authoritative가 붙음
• 일반적으로 도메인/호스팅 업체의 네임서버를 말함
• 개인 DNS 구축해도 이 경우에 해당

Recursive DNS 서버 (권한 없는 DNS Server)

• DNS 서버는 도메인 네임 스페이스를 위한 권한 있는 DNS 서버와 권한이 없는 DNS 서버로 구분됨
• 위 3개의 서버는 권한 있는 DNS 서버임
• 인터넷 사용자가 가장 먼저 접근하는 DNS 서버
• 네임 스페이스를 위한 권한 있는 DNS 서버는 IP 주소와 도메인 이름을 매핑함
• 네임 스페이스를 위한 권한 없는 DNS 서버는 질의를 통해 IP 주소를 알아내거나 캐시함

DNS 서버에게 IP 주소를 요청할 때, 왜 UDP를 사용하나?

빠른 속도

• TCP의 경우 데이터 전송 전에 연결을 맺는 handshaking 과정이 있는 반면, UDP는 연결 설정에 드는 비용이 없음
• 웹 사이트 로딩 속도 향상, 인터넷 대역폭 최적화 등 DNS질의는 빠른 응답성(신속성)이 중요함
• UDP는 512 바이트를 넘어가지 않는 작은 크기의 패킷만 전송이 가능하고, 오버헤드가 없어 TCP에 비해 상대적으로 빠름

연결 상태를 유지할 필요가 없다

• TCP의 패킷 안에는 여러 정보가 담겨 있지만, UDP는 어떤 정보도 기록하지 않고 유지할 필요가 없음
• 따라서 DNS 서버는 TCP보다 많은 클라이언트를 수용할 수 있으므로 연결 상태를 유지하지 않고 정보 기록을 최소화할 수 있는 UDP를 채택함

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

손실을 방지하기 위해서는?

• 체크섬(Checksum): DNS는 각 패킷의 체크섬 값을 계산하여 데이터 무결성을 검사함
  체크섬 결과에 의해 패킷이 손상되었다는 것을 판단하면, 수신 측에서 패킷을 폐기
• 재시도: DNS 클라이언트는 요청에 대한 응답을 일정 시간 내에 수신하지 못하면 재시도함
  DNS 서버는 요청에 대한 응답을 보낼 수 없거나, 시간이 초과되면 응답 대신 재시도 메시지를 보냄
• TTL(Time to Live): DNS 서버는 응답 메시지에 TTL 값을 포함시킴. 이 값은 해당 패킷의 유효 기간을 나타내며, 클라이언트는 이 값에 따라 DNS 결과를 캐시 하고, 유효기간이 지난 결과는 폐기함으로써 DNS 서버에서 발생하는 데이터 손실 문제를 방지할 수 있음

DNS 레코드

• DNS의 기본 구성 요소
• 이를 통해 도메인이 웹사이트, 이메일 주소 또는 인터넷의 다른 리소스를 가리키도록 할 수 있음
• 도메인 네임에 대한 기타 정보를 구성하고 제어할 수 있는 DNS 데이터베이스에 저장된 특정 리소스 레코드
• 이 레코드는 웹사이트가 호스팅되는 방식과 웹사이트에 액세스할 수 있는 항목을 정의함

UDP란?

• UDP(User Datagram Protocol)는 TCP와 함께 데이터 그램으로 알려진 단문 메시지를 교환하기 위해 사용하는 비연결형 프로토콜
• 데이터만 보내고 확인 응답과 같은 절차를 생략할 수 있으므로 통신의 신속성을 높임
• 주로 DNS, VoIP(Voice over IP) 등에 사용됨 (예시: 실시간 스트리밍, 온라인 게임 등)

UDP의 장점과 단점

장점

• 빠른 속도 (TCP보다 속도가 빠름)

단점

• 신뢰성이 낮음
• 흐름 제어(flow control)가 없어서 제대로 전송되었는지, 오류가 없는지 확인할 수 없음

UDP 체크섬(Checksum)

• UDP의 체크섬은 데이터그램의 무결성을 확인하기 위해 사용됨
• 16비트의 값으로 계산되며, 오류가 있는 경우 0으로 설정됨
• 수신측에서 체크섬이 0인 경우 데이터그램이 손상되었음을 의미하며, 데이터그램을 폐기함
• 체크섬은 데이터그램의 헤더와 데이터를 모두 포함하여 계산되며, 수신측에서 계산된 체크섬과 송신측에서 전송한 체크섬을 비교하여 데이터그램이 손상되었는지 확인함

  But, UDP의 체크섬은 데이터그램의 무결성을 보장하는 데 도움이 되지만, 데이터그램의 손실을 보장하지는 않음
  UDP는 비연결형 프로토콜이기 때문에 데이터그램이 손실되거나 도착하지 않을 수 있음

신뢰적 데이터 전송의 원리

전송 후 대기(Stop-and-Wait 방식) 프로토콜

• 하나의 패킷을 전송 후 정지 대기하는 프로토콜
• 송신 측에서 1개의 패킷을 송신하고 수신 측에서 수신된 패킷의 에러 유무를 판단하며 송신 측에 ACK(긍정 응답 프레임) 또는 NAK(부정 응답 프레임)를 보냄
• 송신 측은 수신측에게 ACK를 받았을 경우에만 다음 패킷을 전송
• NAK를 받았거나 일정시간 까지 ACK 또는 NAK를 받지 못하면 에러 발생으로 간주하고 해당 패킷을 재전송함
• 구현 방식이 단순하지만 수신측이 ACK 혹은 NAK를 받을 때까지 다음 프레임을 받을 수 없으므로 전송 효율이 떨어지는 단점이 있음(속도가 느림)

파이프라인 프로토콜(Pipeline Protocol)

• 한 번 보낼 때 여러 개의 패킷을 전송하는 프로토콜

• 송신측에서 한 번에 패킷을 여러 개 보내고 이후 보낸 여러 개의 패킷 중 첫 데이터가 ACK을 송신 측에게 보내면 두번째 패킷을 한 번에 보내게 됨 이런 과정을 반복

• 이 과정에서 전송된 패킷에 대해 피드백을 받지 않고도 다음 패킷들을 전송하도록 허용하여 링크 이용률을 높이기 때문에 속도가 훨씬 더 빨라짐

• 이 파이프라인 프로토콜을 구축하기 위한 방법에는 대표적으로 GBN ARQ 기법과 SR ARQ 기법이 있음

  GBN(Go-Back-N) ARQ 기법

  • Go-Back-N 방식은 송신 측에서 전송할 패킷의 개수를 정함
  • 버퍼에 그 개수만큼의 패킷을 저장하여 전송
  • 버퍼를 window, 버퍼의 사이즈를 window size라고 함
  • 버퍼의 시작점인 send_base, 다음에 보낼 패킷 번호인 next_seq_num을 가짐
  • 수신 측은 이번에 받을 패킷의 번호를 기억하고 있음
  • 이때 수신측은 누적 ACK(Cumulative ACK)을 사용
  • 각 버퍼가 전송될 때 ACK를 받지 못한 가장 오래된 패킷의 Timer를 기준으로 Timeout이 발생
  • Timeout 이 발생하면 window에 있는 모든 패킷을 전송

  SR(Selective-Repeat) ARQ 기법

  • GBN의 비효율성을 해결하기 위한 방식
  • 송신측은 각 패킷마다 timer를 설정하고 timeout 된 패킷만 재전송 (GBN처럼 버퍼 모두를 전송하지 않음)
  • 수신 측도 버퍼(window)를 가지고 있음
  • 수신 측은 기다리던 패킷이 오면 바로 상위 계층으로 전달하고 ACK 신호를 보냄
  • 수신 측은 기다리고 있던 패킷이 오지 않으면 일단 버퍼에 넣어놓고 ACK 신호를 보냄
  • 수신 측의 버퍼가 가득 차면(패킷이 모두 도착하면) 상위 계층으로 전달
  • 이외는 GBN과 비슷함
  • GBN보다 효율적으로 보이지만 모든 패킷에 timer가 있기 때문에 overhead가 큼

슬라이딩 윈도우 프로토콜(Sliding Window Protocol)

• 데이터 통신에서 사용되는 흐름 제어 기법 중 하나
• 송신자와 수신자가 각각 윈도우라는 버퍼를 가지고 있으며, 윈도우의 크기에 따라 한 번에 보낼 수 있는 패킷의 개수가 결정됨
• 슬라이딩 윈도우는 윈도우의 크기를 동적으로 조절하면서 효율적인 패킷 전송을 가능하게 함
• 즉, 패킷을 전송할 때 수신자로부터 승인을 받기 전에 송신자가 전송할 수 있는 데이터의 양을 규제하는 흐름 제어 메커니즘

참조
HTTPS와 SSL
SSL과 TLS
SSL과 TLS 작동 방식
HTTPS 작동 원리
DNS와 작동 원리
DNS 레코드
신뢰적 데이터 전송의 원리
파이프라인 프로토콜