이 영역을 누르면 첫 페이지로 이동
codesche's blog 블로그의 첫 페이지로 이동

codesche's blog

페이지 맨 위로 올라가기

codesche's blog

네트워크

  • 2023.03.16 20:35
  • Study Cafe/기술면접

1. 웹 통신의 큰 흐름

○ 웹 통신 과정 (이해)

● 사용자가 웹 브라우저를 통해 URL을 입력합니다.

● 입력된 URL 중 도메인 네임을 DNS 서버에서 검색합니다.

● DNS 서버에서 해당 도메인 네임에 해당하는 IP 주소를 찾아 사용자가 입력한 URL 정보와 함께 전달합니다.

● 웹 페이지 URL 정보와 전달받은 IP 주소를 이용해 HTTP 요청 메세지를 생성합니다.

● 요청은 TCP를 통해 서버로 전송됩니다.

● 서버는 클라이언트의 요청을 받고 응답을 전송합니다.

 

*Chrome을 실행시켜 주소창에 특정 URL을 입력시키면 어떤 일이 일어나는가?
브라우저가 URL에 적힌 값을 파싱해서 HTTP request Message를 만들고, OS에 전송 요청을 합니다. 이 때, Domain으로 요청을 보낼 수 없기 때문에 DNS Lookup을 수행합니다.

 

◆ DNS 룩업과정

브라우저 -> host파일 -> DNS Cache 순서로 도메인에 매칭되는 IP를 찾습니다. 보통은 루트 도메인서버에서부터 서브 도메인 서버순으로 찾게 됩니다.

 

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

 

패킷은 스위칭 허브 등을 경유하여 인터넷 접속용 라우터에서 ISP로 전달되고 인터넷으로 이동합니다.
액세스 회선에 의해 통신사용 라우터로 운반되고 인터넷의 핵심부로 전달됩니다.

고속 라우터들 사이로 목적지까지 패킷이 흘러들어가게 됩니다.

 

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

 

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

 

 

2. TCP와 UDP의 차이점

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

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

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

 

 

3. TCP 3, 4 way handshake에 대해 설명

TCP 3way handshake는 가상회선을 수립하는 단계입니다. 클라이언트는 서버에 요청을 전송할 수 있는지, 서버는 클라이언트에게 응답을 전송할 수 있는지 확인하는 과정입니다. SYN, ACK 패킷을 주고받으며, 임의의 난수로 SYN 플래그를 전송하고, ACK 플래그에는 1을 더한값을 전송합니다. 정확한 순서는 SYN(n) -> ACK(n + 1), SYN(m) -> ACK(m + 1) 순으로 일어납니다.

 

(SYN 은 synchronize sequence numbers ACK는 acknowledgements 의 약자)

 

## 진행 과정 ##

  1. 클라이언트(A)는 서버(B)에 접속을 요청하는 SYN 패킷을 보냅니다. 이때 클라이언트(A)는 SYN을 보내고 SYN/ACK 응답을 기다리는 SYN_SENT 상태가 됩니다.
  2. 서버(B)는 Listen 상태로 포트 서비스가 가능한 상태여야 합니다. (Closed :닫힌상태) 서버(B)는 SYN 요청을 받고 클라이언트(A)에게 요청을 수락한다는 ACK와 SYN flag가 설정된 패킷을 발송하고 클라이언트(A)가 다시 ACK으로 응답하기를 기다린다. 이때 서버(B)는 SYN_RECEIVED 상태가 됩니다.
  3. 클라이언트(A)는 서버(B)에게 ACK을 보낸 이후부터는 연결이 되며 데이터 전송이 가능해집니다. 이때의 서버(B) 상태는 성립(ESTABLISHED) 상태가 됩니다.

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

 

## 진행과정 ##

  1. FIN (+ACK) 서버와 클라이언트가 TCP 연결이 되어있는 상태에서 클라이언트가 접속을 끊기 위해 close( )를 호출합니다. 클라이언트가 close( )를 호출하면서 서버에게 FIN 패킷을 보내게 되고 클라이언트는 FIN_WAIT_1 상태로 들어갑니다.
  2. ACK 서버는 클라이언트에게 응답을 보내고 CLOSE_WAIT 상태에 들어갑니다. 그리고 아직 남은 데이터가 있는 경우 전송을 마친 후에 close( )를 호출합니다.
  3. FIN_WAIT_2 클라이언트에서는 서버에서 ACK를 받은 후에 서버가 남은 데이터 처리를 끝내고 FIN 패킷을 보낼 때까지 기다리게 됩니다.
  4. FIN 서버는 이제 모든 데이터 처리가 끝났다고 종료에 합의 한다는 뜻으로 클라이언트에게 FIN 패킷을 보낸 후에 승인 번호를 보내줄 때까지 기다리는 LAST_ACK 상태로 들어갑니다.
  5. ACK 클라이언트는 서버에서 FIN 패킷을 받고 나서 다시 서버에게 ACK 응답을 보낸 후에 TIME_WAIT 상태로 들어가며 실질적인 종료 과정(CLOSED)에 들어가게 됩니다. 이때 TIME_WAIT 상태는 의도치 않은 에러로 인해 연결이 데드락으로 빠지는 것을 방지하는데, 만약 에러로 인해 종료가 지연되다가 타임이 초과되면 CLOSED로 들어갑니다.
  6. CLOSED 서버는 ACK를 받고 CLOSED 상태로 들어가 종료합니다.

 

 

💡 TIME_WAIT 이란?

서버가 FIN을 전송하기 전에 전송한 ACK 패킷이 Routing 지연이나 패킷 유실로 인한 재전송으로 FIN 패킷보다 늦게 도착 할 수 있습니다. 이 경우 데이터가 유실되기 때문에 이를 대비하여 클라이언트는 서버로부터 FIN을 수신하더라도 일정시간(2MSL time out = Maximum Segment Lifetime의 2배) 동안 세션을 남겨 놓아야 하는데 이러한 잉여 패킷을 기다리는 과정을 TIME_WAIT이라고 합니다.

 

4. HTTP와 HTTPS의 차이점

HTTP는 따로 암호화 과정을 거치지 않기 때문에 중간에 패킷을 가로채거나 수정할 수 있습니다. 따라서 보안이 취약합니다. 취약한 보안 문제를 해결하기 위해 등장한 것이 HTTPS입니다. 중간에 암호화 계층을 거쳐서 패킷을 암호화합니다.

 

5. HTTPS, SSL Handshake에 설명

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

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

클라이언트는 TCP 3way handshake를 수행한 이후 Client Hello를 전송합니다. 서버는 인증서를 보냅니다.

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

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

 

 

6. GET과 POST의 차이점

*둘 다 HTTP 프로토콜을 이용하여 서버에 무엇인가를 요청할 때 사용하는 방식.

 

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

 

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

 

 

7. HTTP 메서드와 하는 역할

● GET 요청은 서버에 존재하는 데이터를 요청하는 것입니다. CRUD로 따지면 R입니다.

● POST 요청은 서버에 데이터를 생성하는 것을 요청합니다. CRUD로 따지면 C입니다.

● PUT 요청은 서버에 존재하는 데이터를 수정하거나 존재하지 않으면 생성합니다. CRUD로 따지면 C,U입니다.

● DELETE 요청은 서버에 데이터를 제거할 것을 요청하며 존재하지 않아도 동일하게 동작합니다.

CRUD로 따지면 D입니다.

● PATCH 요청은 서버에 존재하는 데이터를 일부 수정합니다. CRUD로 따지면 U입니다.

 

 

8. RESTful

RESTful은 일반적으로 REST라는 아키택처를 구현하는 웹 서비스를 나타내기 위해 사용되는 용어입니다. 즉 'REST API'를 제공하는 웹 서비스를 'RESTful' 하다고 말할 수 있습니다. RESTful을 사용하는 목적은 성능 향상이 아니라 일관적인 컨벤션을 통한 API의 이해도 및 호환성을 높이는 것입니다. 쉽게 말해 이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것입니다.

 

 

9. CORS

CORS(Cross-Origin Resource Sharing)는 서로 다른 도메인간에 자원을 공유하는 것을 뜻합니다. 웹개발을 하다가 흔히 접하는 이슈이며 프론트엔드 개발시 로컬에서 API 서버에 요청을 보낼 때 발생합니다. 대부분의 브라우저에서는 이를 기본적으로 차단하는데 서버측에서 헤더를 통해 사용가능한 자원을 알려줍니다. 

 

 

10. OSI계층과 그 존재 이유, TCP/IP 4계층

OSI7계층은 네트워크 통신을 구성하는 요소들을 7개의 계층으로 표준화 한 것입니다. 표준화하는 것의 장점은 통신이 일어나는 과정을 단계별로 파악할 수 있어, 문제 발생시 해당 문제를 쉽게 해결할 수 있습니다. 실제로 우리가 대부분 사용하는 네트워크는 TCP/IP 4계층입니다. 통신에 실제로 사용되는 계층이고 1,2 계층이 1계층, 5, 6, 7계층이 4계층으로 운영됩니다.

 

 

참고링크:

https://github.com/corrvax/ComputerScienceStudy/blob/main/network/TCP%203-way%20Handshake.md

https://yaelimeee.tistory.com/50

https://github.com/JaeYeopHan/Interview_Question_for_Beginner/tree/master/Network#%EC%9B%B9-%ED%86%B5%EC%8B%A0%EC%9D%98-%ED%81%B0-%ED%9D%90%EB%A6%84

http://asfirstalways.tistory.com/356

https://gmlwjd9405.github.io/2018/09/21/rest-and-restful.html

https://sudo-minz.tistory.com/184

'Study Cafe > 기술면접' 카테고리의 다른 글

자료구조/알고리즘, 컴파일러  (1) 2023.04.17
Spring  (0) 2023.04.09
데이터베이스 + JPA  (0) 2023.03.27
백엔드 개발 면접 질문 주요 리스트(1)  (0) 2023.01.30
기술 면접 주요 질문 답변 정리(5문항)  (0) 2022.12.25

댓글

이 글 공유하기

  • 구독하기

    구독하기

  • 카카오톡

    카카오톡

  • 라인

    라인

  • 트위터

    트위터

  • Facebook

    Facebook

  • 카카오스토리

    카카오스토리

  • 밴드

    밴드

  • 네이버 블로그

    네이버 블로그

  • Pocket

    Pocket

  • Evernote

    Evernote

다른 글

  • Spring

    Spring

    2023.04.09
  • 데이터베이스 + JPA

    데이터베이스 + JPA

    2023.03.27
  • 백엔드 개발 면접 질문 주요 리스트(1)

    백엔드 개발 면접 질문 주요 리스트(1)

    2023.01.30
  • 기술 면접 주요 질문 답변 정리(5문항)

    기술 면접 주요 질문 답변 정리(5문항)

    2022.12.25
다른 글 더 둘러보기

정보

codesche's blog 블로그의 첫 페이지로 이동

codesche's blog

  • codesche's blog의 첫 페이지로 이동

검색

메뉴

  • 홈
  • 태그
  • 방명록

카테고리

  • 분류 전체보기 (76)
    • Algorithm (15)
      • 백준 (3)
      • 프로그래머스 (10)
      • inflearn 알고리즘(Java) (2)
    • 블로그소개 (1)
    • Back-End (11)
      • Java (10)
      • SpringBoot (1)
    • Database (2)
      • MySQL (0)
      • MariaDB (1)
      • Redis (0)
      • 개념, 이론 (1)
    • Front-End (0)
      • html, css, javascript (0)
    • Git (2)
    • 알고리즘 지식 (11)
      • 자료구조 (11)
    • Study Cafe (21)
      • 기술면접 (6)
      • Clean Code 스터디 (14)
      • CS 스터디 (0)
      • 개발용어 (1)
    • 주간 에세이 (10)
    • DevOps (3)
      • 배포, Front&Back 연동 (1)
      • AWS (0)
      • Docker (1)
      • 이론 (1)

최근 글

인기 글

댓글

공지사항

아카이브

태그

  • 자료구조
  • 자바 변수
  • git commit
  • java
  • 주간에세이
  • 자바 기초
  • 개발자 현실
  • 클린코드

나의 외부 링크

정보

The Code의 codesche's blog

codesche's blog

The Code

블로그 구독하기

  • 구독하기
  • RSS 피드

방문자

  • 전체 방문자
  • 오늘
  • 어제

티스토리

  • 티스토리 홈
  • 이 블로그 관리하기
  • 글쓰기
Powered by Tistory / Kakao. © The Code. Designed by Fraccino.

티스토리툴바