[Network] CS 스터디 7주차

Published: 2024-09-18
Updated: 2024-09-18

깃허브 인터뷰 레포지토리

4-Way Handshake에 대해 설명해 주세요.

TCP의 두 가지 연결 해제 방식 중 하나입니다.
연결 종료는 양쪽 호스트 모두 먼저 시도할 수 있습니다.
- 연결을 요청하는 Host: 클라이언트
- 연결을 요청 받는 Host: 서버
TCP는 양방향 통신이기에 클라이언트-클라이언트 형태가 존재합니다.

ACK(Acknowledgement)
- 패킷을 받았다는 응답을 할 때 사용합니다.
- ACK Number가 유효한지를 나타냅니다.
- 최초 연결의 첫 번째 세그먼트를 제외한 모든 Segment의 ACK 비트는 1로 설정합니다.
  - 최초 연결의 첫 번째 Handshake 과정에서는 응답할 요청이 없기 때문입니다.
FIN(Finish)
- TCP 연결을 종료할 때 사용합니다.
- 더 이상 전송할 데이터가 없음을 의미합니다.
RST(Reset)
- TCP 연결을 강제로 종료할 때 사용합니다.
- 비정상적인 세션 연결 끊기에 해당합니다.
- 연결을 즉시 끊고자 할 때 사용합니다.

클라이언트 ———(FIN)———> 서버
1. 클라이언트가 서버에게 연결 종료를 요청하는 FIN 세그먼트를 보낸다.
  1. 세그먼트 헤더 내에 FIN 비트를 1로 설정한다.
2. 이때 FIN 패킷에는 실질적으로 ACK도 포함되어있다.
3. 클라이언트는 전송 후 FIN-WAIT-1 상태가 된다.
클라이언트 <———(ACK)——— 서버
1. 서버는 FIN을 받고, 확인했다는 ACK를 클라이언트에게 보내고 자신의 통신이 끝날때까지 기다린다.
2. 아직 남은 데이터가 있다면 마저 전송을 마친 후에 close( )를 호출한다.
3. 클라이언트는 ACK를 받은 후에 서버가 남은 데이터 처리를 끝내고 FIN 패킷을 보낼 때까지 기다린다. (FIN_WAIT_2)
클라이언트 <———(FIN)——— 서버
1. 서버가 데이터를 모두 보냈다면, 연결 종료에 합의 한다는 의미로 FIN 패킷을 클라이언트에게 보낸다.
2. 이후 ACK를 받을때까지 기다리는 LAST_ACK 상태가 된다.
클라이언트 ———(ACK)———> 서버
1. 클라이언트는 FIN을 받고, 응답 ACK를 서버에게 보낸다.
2. 아직 서버로부터 받지 못한 데이터가 있을 수 있으므로 TIME_WAIT을 통해 기다린다.
  1. TIME_WAIT 상태는 의도치 않은 에러로 인해 연결이 데드락으로 빠지는 것을 방지한다.
CLOSED
- 서버는 ACK를 받은 이후 소켓을 닫는다 (Closed)
- TIME_WAIT 시간이 끝나면 클라이언트도 소켓을 닫는다 (Closed)

패킷이 4-way handshake 목적인지 어떻게 파악할 수 있을까요?

TCP 헤더 내의 플래그를 확인함으로써 알 수 있습니다.
- FIN 플래그와 ACK 플래그의 설정 여부를 통해, 해당 패킷이 연결 종료 과정의 일부인지를 파악할 수 있습니다.

빨리 끊어야 할 경우엔, (즉, 4-way Handshake를 할 여유가 없다면) 어떻게 종료할 수 있을까요?

아까 말씀드렸던 RST(Reset) 패킷을 사용하여 즉시 연결을 종료할 수 있습니다.

ACK를 보내거나 기다리는 작업이 필요하지 않고, 바로 연결이 종료됩니다.
RST 비트를 1로 설정한 세그먼트를 전송합니다.
- 송신자는 패킷을 보내고 바로 연결을 종료
- 수신자는 패킷을 받으면 바로 연결을 종료

RST를 사용해 연결을 종료하는 경우

보안 위반의 경우
1. 악성 코드가 존재한다고 판단되면 연결을 즉시 종료하여 보호할 수 있습니다.
자원이 부족해 자원 할당을 해제해야하는 경우
TCP 연결에 장애가 발생한 경우
1. 즉시 연결을 끊고 새로운 연결을 시도해 정상적인 통신으로 돌아올 수 있습니다.

4-Way Handshake 과정에서 중간에 한쪽 네트워크가 강제로 종료된다면, 반대쪽은 이를 어떻게 인식할 수 있을까요?

TCP timeout을 통해 인식할 수 있습니다.

4-way handshake의 각 단계마다 타임아웃이 설정됩니다.
예상 시간 내에 응답이 오지 않으면 연결이 실패한 것으로 간주됩니다.
예를 들어
- 4-way handshake에서 첫 번째 FIN 패킷을 보낸 후에 상대방으로부터 ACK를 받지 못했다면, TCP는 타임아웃을 트리거하고 연결 종료를 다시 시도하거나 상위 계층에 에러를 알립니다.

더 많은 예시 (공부용)

FIN_WAIT_1 상태에서의 타임아웃
1. 호스트 A가 FIN 패킷을 보내고 FIN_WAIT_1 상태로 진입합니다.
2. 일반적으로 75초 동안 상대방의 ACK를 기다립니다.
3. 75초 후에도 ACK가 오지 않으면, 연결이 비정상적으로 종료된 것으로 간주합니다.
FIN_WAIT_2 상태에서의 타임아웃
1. 호스트 A가 FIN_WAIT_2 상태에서 상대방의 FIN을 기다립니다.
2. 많은 구현에서 10분의 타임아웃을 설정합니다.
3. 10분 후에도 FIN이 오지 않으면, 연결을 강제로 종료합니다.
CLOSING 상태에서의 타임아웃
1. 양쪽이 동시에 FIN을 보낸 경우 CLOSING 상태로 진입합니다.
2. 이 상태에서 ACK를 기다리는 시간은 일반적으로 1-2분입니다.
3. 이 시간 내에 ACK가 오지 않으면 연결을 종료합니다.
LAST_ACK 상태에서의 타임아웃
1. 호스트 B가 FIN을 보내고 LAST_ACK 상태로 진입합니다.
2. 대략 30초에서 2분 사이의 타임아웃을 설정합니다.
3. 이 시간 내에 ACK가 오지 않으면, 연결을 종료하고 리소스를 해제합니다.

왜 종료 후에 바로 끝나지 않고, TIME_WAIT 상태로 대기하는 것 일까요?

서버는 마지막 FIN을 보내기 전에 아직 전송하지 못한 데이터를 전송할 수 있습니다.
- 그러나, 데이터가 유실되어 재전송하거나 지연되어 FIN보다 늦게 도착할 수 있습니다.
즉, 클라이언트는 FIN을 받고도 TIME_WAIT를 통해 혹시 모를 패킷 수신을 기다립니다.

[www.github.com을](http://www.github.xn–com-of0o/) 브라우저에 입력하고 엔터를 쳤을 때, 네트워크 상 어떤 일이 일어나는지 최대한 자세하게 설명해 주세요.

DNS 조회
1. 브라우저는 먼저 자체 캐시, 운영 체제 캐시, 라우터 캐시, ISP 캐시 순으로 DNS 항목을 확인합니다.
2. 캐시에서 찾지 못하면 ISP의 DNS 서버가 www.github.com의 IP 주소를 찾기 위한 DNS 쿼리를 시작합니다.
IP 주소 확인
1. DNS 쿼리를 통해 www.github.com의 IP 주소를 얻습니다. 이 IP 주소는 GitHub 웹사이트를 호스팅하는 서버의 주소입니다.
TCP 연결 설정
1. 브라우저는 확인된 IP 주소로 TCP 연결을 시작합니다.
2. 3-way handshake를 통해 연결됩니다.
  1. 클라이언트가 SYN 패킷을 서버에 보냅니다.
  2. 서버는 SYN-ACK로 응답합니다.
  3. 클라이언트가 ACK를 보내 연결을 확정 짓습니다.
HTTPS 요청
1. TCP 연결이 설정되면 브라우저는 HTTPS GET 요청을 웹 서버로 보냅니다.
  1. 이 요청에는 브라우저 정보, 원하는 페이지 등의 데이터가 포함됩니다.
서버 응답
1. GitHub의 웹 서버가 요청을 처리합니다.
2. 서버는 요청된 페이지의 HTML, CSS, JavaScript 등을 포함한 응답을 생성합니다.
3. 서버는 HTTP 응답과 함께 상태 코드(예: 200 OK)를 보냅니다.
데이터 전송
1. 서버의 응답이 네트워크를 통해 브라우저로 전송됩니다. 이 과정에서 데이터는 작은 패킷으로 나뉘어 전송됩니다.
브라우저 렌더링
1. 브라우저가 받은 HTML 내용을 표시합니다.
2. 추가적인 리소스(이미지, CSS, JavaScript 등)가 필요한 경우, 브라우저는 이 리소스를 위한 별도의 요청을 보냅니다.
연결 종료 또는 유지
1. 페이지 로딩이 완료되면 TCP 연결은 종료되거나, 추가 요청을 위해 유지될 수 있습니다.
2. 이 과정을 통해 www.github.com 웹페이지가 사용자의 브라우저에 표시됩니다. 전체 과정은 보통 1초 이내에 완료되며, 네트워크 상태와 서버의 응답 속도에 따라 달라질 수 있습니다.

DNS 쿼리를 통해 얻어진 IP는 어디를 가리키고 있나요?

DNS 쿼리를 통해 얻어진 IP 주소는 GitHub의 서버를 가리키고 있습니다. 이 과정은 다음과 같습니다.

사용자가 www.github.com을 입력하면 DNS 리졸버가 이 정보를 찾기 시작합니다.
리졸버는 루트 서버, TLD 서버를 거쳐 최종적으로 GitHub의 권한 있는 네임서버에 도달합니다.
GitHub의 네임서버는 www.github.com에 대한 정확한 IP 주소를 제공합니다.
최종적으로 DNS 쿼리는 GitHub 서버의 IP 주소를 반환합니다.

Web Server와 Web Application Server의 차이에 대해 설명해 주세요.

Web Server와 Web Application Server(WAS)는 웹 서비스를 제공하는 데 사용되는 서버 유형이지만, 그 역할과 기능에는 중요한 차이가 있습니다.

Web Server

정적 콘텐츠 제공: HTML, CSS, 이미지 파일 등 변하지 않는 정적 파일들을 클라이언트에게 전송합니다.
HTTP 프로토콜 사용: 클라이언트의 HTTP 요청을 처리하고 응답합니다.
리소스 효율: 정적 콘텐츠 처리에 특화되어 있어 상대적으로 적은 리소스를 사용합니다.
예: Apache, Nginx 등

Web Application Server (WAS)

동적 콘텐츠 생성: 사용자 요청에 따라 데이터를 처리하고 동적으로 콘텐츠를 생성합니다.
비즈니스 로직 처리: 데이터베이스 연동, 트랜잭션 처리 등 복잡한 비즈니스 로직을 수행합니다.
다양한 프로토콜 지원: HTTP 외에도 RPC, RMI 등 다양한 프로토콜을 지원합니다.
리소스 필요: 동적 처리로 인해 Web Server보다 더 많은 리소스를 필요로 합니다.
예: Tomcat 등

차이점

콘텐츠 처리: Web Server는 정적 콘텐츠, WAS는 동적 콘텐츠를 주로 처리합니다.
기능: WAS는 Web Server의 기능을 포함하면서 추가적인 기능을 제공합니다.
리소스 사용: WAS는 더 복잡한 처리를 수행하므로 일반적으로 더 많은 리소스를 필요로 합니다.
보안: Web Server는 주로 클라이언트와의 통신 보안을, WAS는 애플리케이션 레벨의 보안을 담당합니다.
확장성: Web Server는 정적 콘텐츠 처리에 특화되어 높은 동시 접속을 처리할 수 있지만, WAS는 로드 밸런싱이 필요할 수 있습니다.

URL, URI, URN은 어떤 차이가 있나요?

URI (Uniform Resource Identifier)

인터넷 상의 리소스를 고유하게 식별하는 문자열입니다.
URL과 URN을 포함하는 상위 개념입니다.
리소스를 식별하는 것이 주 목적이며, 위치나 이름을 모두 포함할 수 있습니다.

URL (Uniform Resource Locator)

URI의 하위 개념으로, 리소스의 위치를 나타냅니다.
프로토콜(http, https 등)과 도메인 이름을 포함합니다.
리소스에 접근하는 방법을 제공합니다.
https://www.google.com처럼 일반적인 주소

URN (Uniform Resource Name)

URI의 또 다른 하위 개념으로, 리소스의 이름을 나타냅니다.
위치에 독립적인 식별자입니다.
리소스의 영구적인 이름을 제공하는 것이 목적입니다.
예: urn:isbn:0451450523 (책의 ISBN 번호)

차이점

URL은 리소스의 위치를, URN은 리소스의 이름을 나타냅니다.
URL은 리소스에 접근하는 방법을 제공하지만, URN은 그렇지 않습니다.
URI는 URL과 URN을 모두 포함하는 더 넓은 개념입니다.

Sully