[CS] 네트워크

buckshot·2024년 4월 18일

cs

목록 보기
2/15
post-thumbnail

이번에는 인터넷에 떠돌고 있는 cs 네트워크 관련한 빈출 질문들에 대해서 찾아보고 정리 하겠다.

브라우저가 URL에 적힌 값을 파싱해서 HTTP Request Message를 만들고 다음으로 OS에 전송을 요청 한다. 이 때 도메인으로 요청을 보낼 수 없기 때문에 DNS LookUp을 수행 한다.

DNS LookUp
크롬의 경우 브라우저 → hosts 파일 → DNS Cache의 순서로 도메인에 매칭 되는 ip를 찾는다.
일반적으로 설명하는 DNS LookUp은 루트 도메인 서버에서 부터 서브 도메인 서버순으로 찾게 된다.

이 요청은 프로토콜 스택이라는 OS에 내장되어 있는 네트워크 제어용 소프트웨어에 의해 패킷에 저장되고 패킷에 제어 정보를 덧붙여 LAN 어답터에 전송하고, LAN어답터는 이를 전기 신호로 변환하여 송출한다.

핵심부를 통과한 패킷은 목적지의 LAN에 도달하고, 방화벽이 패킷을 검사한 후 캐시 서버로 보내어 웹 서버에 갈 필요가 있는지 등을 검사한다.

웹 서버에 도착한 패킷은 프로토콜 스택이 패킷을 추출하여 메세지 복원하고 웹 서버 어플리케이션에 넘겨준다. 어플리케이션은 요청에 대한 응답 데이터를 작성하여 클라이언트로 회송하고, 이는 전달된 방식 그대로 전송 된다.

  • TCP와 UDP의 차이점

TCP는 연결 지향형 프로토콜이고 UDP는 데이터를 데이터그램 단위로 전송하는 프로토콜이다.

TCP는 가상 회선을 만들어 신뢰성을 보장하도록 (흐름 제어, 혼잡 제어, 오류제어) 하는 프로토콜로 따라 신회성을 보장하기 위한 절차가 없는 UDP에 비해 속도가 느린 편이다.

TCP는 그래서 파일 전송과 같은 신뢰성이 중요한 서비스에 사용되고, UDP는 스트리밍, RTP와 같이 연속성이 더 중요한 서비스에 사용이 된다.

하지만 UDP도 신뢰성을 UDP 자체에서 보장하지 않는 것 뿐이지 개발자가 직접 신회성을 보장하도록 할 수 있다. 그래서 HTPP/3는 QUIC라는 프로토콜을 기반으로 하는데 QUIC는 UDP를 기반으로 한다.
즉 UDP 자체는 신뢰성을 보장하지 않지만, 추가적인 정의를 통하여 신뢰성을 보장 받을 수 있다.

  • 3/4 Way Handshake??

TCP가 가상 회선을 만들고 제거하는 과정에서의 질문이다. TCP관련하여 학습을 했는지 확인하는 질문이다.

TCP 3 Way Handshake는 가상 회선을 수립하는 단계이다. 클라이언트는 서버에 요청을 전송할 수 있는지, 서버는 클라이언트에게 응답을 전송할 수 있는지 확인하는 과정이다. SYN, ACK패킷을 주고 받으며, 임의의 난수로 SYN플래그를 전송하고, ACK플래그에는 1을 추가한 값을 전송한다.

TCP 4 Way Handshake는 TCP연결을 해제하는 단계로 클라이언트는 서버에게 연결해제를 통지하고 서버가 이를 확인하고 클라이언트에게 이를 받았음을 전송해주고 마지막으로 연결이 해제가 된다.
단, 서버에서 소켓이 닫혔다고 통지해도 클라이언트 측에서 일정시간 대기하는데, 혹시나 패킷이 나중에 도착할 수 있기 때문이다.

  • HTTP와 HTTPS의 차이점

HTTP는 자체적으로 암호화 과정을 생략하기 때문에 중간에 패킷을 가로채거나 수정할 수 있다. 이러한 점들을 보완하기 위하여 HTTPS가 나타났다. 중간에 암호화 계층을 거쳐서 패킷을 암호화한다.

  • HTTPS에 대해서 설명하고 SSL Handshake에 관련하여 설명

HTTPS는 HTTP에서 보안 계층을 추가한 것이다. HTTPS는 제 3자 인증, 공개키 암호화, 비밀키 암호화를 사용한다.

제 3자 인증은 믿을 수 있는 인증기관에 등록된 인증서만 신뢰하는 것이고, 공개키 암호화는 비밀키를 공유하기 위하여 사용된다.

클라이언트는 TCP 3 Way Handshake를 수행한 후 Client Hello를 전송한다. 서버는 인증서를 보낸다.

클라이언트는 받은 인증서를 신뢰하기 위해서 등록된 인증기관인지 확인을 한다. 이 인증서는 인증기관의 개인키로 암호화 되어있고, 공개키로 검증할 수 있다. 클라이언트는 사이트 정보와 서버의 공개키를 얻을 수 있다.

서버의 공개키로 통신에 사용 할 비밀키를 암호화 해서 서버에 보낸다. 서버는 이를 개인 키로 확인하고 이후 통신은 공유된 비밀키로 암호화되어 통신한다.

  • GET과 POST의 차이점

GET 요청은 서버에 존재하는 정보를 요청합니다. 이 때 반환되는 정보는 정보 자체가 아니라 정보의 표현이다.
일반적으로 Request Body는 입력하지 않는 것이 일반적이며, 레거시 시스템의 경우 요청을 받아 들이지 않을 수 있다. 캐싱을 수행하기 때문에 캐싱되지 않는 요청은 GET요청이 맞지 않을 수 있다.

POST 요청은 서버에 정보를 생성하는 것을 요청한다. 예전에 HTTP 통신은 POST 요청으로 데이터가 삭제, 수정도 form요청으로 같이 수행했다.
POST 요청은 서버의 상태를 변경시키기 때문에 멱등성이 유지되지 않는다. 보통 Request Body 요청하는 데이터를 담아 전송한다.

profile
let's go insane

0개의 댓글