1월 16일 목요일: 4장(1) 스터디

[kwaksj329]

4장: 커넥션 관리

곽수정: link
유미라: link
윤태연: link
최선아: link

[ssum1ra]

소켓 API와 웹소켓은 어떻게 다른가요?

[ssum1ra]

소켓 API

• TCP/UDP 소켓을 다루는 저수준의 인터페이스
• 기본적인 네트워크 연결을 설정하고 데이터를 송수신한다.

웹소켓

• 웹 환경에서 실시간 통신을 가능하게 하는 고수준의 소켓 프로토콜
• 클라이언트와 서버 간의 지속적인 연결을 유지하며 데이터를 양방향으로 주고 받는다.

결국, 소켓이라는 단어는 통신을 가능하게 하는 연결 지점을 의미한다.

[rhino-ty]

문법적 유사성

1. 연결 설정

   • 소켓: socket.connect()
   • 웹소켓: new WebSocket(url)

2. 데이터 전송

   • 소켓: socket.send()
   • 웹소켓: webSocket.send()

3. 데이터 수신

   • 소켓: socket.recv()
   • 웹소켓: webSocket.onmessage = function(event) { ... }

4. 연결 종료

   • 소켓: socket.close()
   • 웹소켓: webSocket.close()

주요 차이점

1. 이벤트 처리

   • 소켓: 주로 동기적 또는 콜백 기반
   • 웹소켓: 이벤트 리스너 기반 (예: onopen, onmessage, onclose)

2. 프로토콜 처리

   • 소켓: 개발자가 직접 프로토콜 구현
   • 웹소켓: WebSocket 프로토콜이 내장되어 있음

3. 에러 처리

   • 소켓: 주로 예외 처리 사용
   • 웹소켓: onerror 이벤트 사용

4. 데이터 형식

   • 소켓: 바이트 스트림 기반
   • 웹소켓: 텍스트 또는 바이너리 데이터 지원

[kwaksj329]

3 -Way Handshake & 4 -Way Handshake를 더 자세히 설명해주세요.

[kwaksj329]

3-Way Handshake

양쪽이 서로 통신할 준비가 되었는지 확인하기 위한 단계

1. SYN (Client → Server)

   • 클라이언트가 연결 요청 세그먼트 전송
   • SYN 플래그 비트를 1로 설정
   • 초기 시퀀스 번호(ISN)를 무작위로 설정

2. SYN + ACK (Server → Client)

   • 서버가 연결 요청 수락 세그먼트 전송
   • SYN과 ACK 플래그 비트를 1로 설정
   • 서버의 ISN 생성
   • ACK Number = 클라이언트의 ISN + 1

3. ACK (Client → Server)

   • 클라이언트가 연결 설정 확인 세그먼트 전송
   • ACK 플래그 비트를 1로 설정
   • ACK Number = 서버의 ISN + 1

4-Way Handshake

양쪽의 데이터 전송이 모두 완료되었는지 확인하는 단계

1. FIN (Client → Server)

   • 클라이언트가 연결 종료 요청 세그먼트 전송
   • FIN 플래그 비트를 1로 설정
   • 클라이언트는 FIN_WAIT_1 상태로 전환

2. ACK (Server → Client)

   • 서버가 확인 세그먼트 전송
   • ACK 플래그 비트를 1로 설정
   • 서버는 CLOSE_WAIT 상태로 전환
   • 클라이언트는 FIN_WAIT_2 상태로 전환

3. FIN (Server → Client)

   • 서버의 남은 데이터 전송 완료 후 FIN 세그먼트 전송
   • FIN 플래그 비트를 1로 설정
   • 서버는 LAST_ACK 상태로 전환

4. ACK (Client → Server)

   • 클라이언트가 최종 확인 세그먼트 전송
   • 클라이언트는 TIME_WAIT 상태로 전환
   • TIME_WAIT는 보통 2MSL(Maximum Segment Lifetime) 동안 유지

[rhino-ty]

항목	3-Way Handshake	4-Way Handshake
목적	TCP 연결 수립	TCP 연결 종료
단계 수	3 단계	4 단계
핸드셰이크 단계	1. SYN : C => S 연결 요청 2. SYN-ACK : S => C 연결 수락 응답 3. ACK : C가 연결 확립	1. FIN 2. ACK 3. FIN 4. ACK
시작 주체	클라이언트가 SYN을 전송	연결을 종료하려는 측이 FIN을 전송
상태 전이	CLOSED → SYN_SENT → ESTABLISHED	ESTABLISHED → FIN_WAIT → TIME_WAIT → CLOSED
주요 역할	연결 설정 및 초기 시퀀스 번호 교환	연결 종료 및 리소스 해제
ACK의 역할	SYN과 SYN-ACK의 수신 확인	FIN의 수신 확인 및 최종 ACK 전송
사용 프로토콜	주로 TCP 연결 수립 시 사용	주로 TCP 연결 종료 시 사용
예시 시나리오	웹 브라우저가 서버에 연결 요청할 때	웹 브라우저가 서버와의 연결을 종료할 때

[choiseona]

[rhino-ty]

왜 HTTP 통신은 확인 응답이 송출 데이터 패킷에 편승할 기회를 감소시키나?

[rhino-ty]

HTTP의 기본적인 동작 방식 때문.

1. 요청-응답 모델 : HTTP는 기본적으로 클라이언트의 요청과 서버의 응답으로 이루어진 단순한 모델 사용, 이로 인해 한 방향으로의 데이터 흐름이 제한적
2. 비대칭적 통신 : 클라이언트가 요청을 보내고 서버가 응답을 보내는 비대칭적인 통신 패턴으로 인해, 같은 방향으로 연속적인 데이터 전송이 적음
3. 단방향성 : 대부분의 경우, 클라이언트가 요청을 보내고 서버가 응답을 보내는 단방향 통신이 주임. 이로 인해 양방향으로 지속적인 데이터 교환이 적어짐.
4. 짧은 연결 지속 시간 : HTTP/1.0 이전의 버전에서는 각 요청마다 새로운 TCP 연결을 생성하고 종료하는 방식 사용. 이로 인해 연결 유지 시간이 짧아 편승 기회가 줄어듦.

이러한 특성으로 인해 HTTP 통신에서는 확인 응답이 송출 데이터 패킷에 편승할 기회가 감소하며, 오히려 확인 응답 지연 알고리즘으로 인한 지연이 자주 발생하게 됩니다.

[rhino-ty]

HTTP와 비교해 HTTPS 연결 중 TCP 연결 과정에 어떤 차이점이 있는가?

[rhino-ty]

TCP 3-Way Handshake 자체는 동일하지만, 추가로 TLS(SSL) Handshake 과정을 거침.

이 과정을 통해 서버 인증서(Certificate)를 교환하고, 대칭 키를 안전하게 협상하며, 암호화 통신을 위한 세션(세션 키)을 생성.
리소스 사용량(CPU, 메모리 등)도 일반 HTTP에 비해 더 늘어나지만, 보안성/신뢰성이 강화됨.

[ssum1ra]

3-Way Handshake 왜 하는지, 어떤 정보를 주고 받는지?

[ssum1ra]

목적

1. 클라이언트-서버 양쪽의 준비 상태 확인
2. 초기 순서 번호 교환
3. 신뢰성 보장

연결 과정

1. 클라이언트 -> 서버 : SYN (연결 요청, 초기 순서 번호 x 전달)

• 클라이언트가 연결을 요청하며 SYN 플래그, 자신의 초기 순서 번호(ISN)와 윈도우 크기를 보냄

2. 서버 -> 클라이언트 : SYN + ACK (연결 수락, 초기 순서 번호 y와 확인 응답 x+1 전달)

• 서버가 연결을 수락하며 SYN과 ACK 플래그를 설정, 자신의 초기 순서 번호(ISN)와 확인 응답 번호, 윈도우 크기를 보냄

3. 클라이언트 -> 서버 : ACK (서버 순서 번호 y+1 확인 응답)

• 클라이언트가 서버의 요청을 확인하며 ACK 플래그를 설정, 상대방의 초기 순서 번호를 확인하고 응답 (서버 순서 번호 y+1 확인 응답)