OSI 7 Layers/TCP/UDP/HTTP

이번주 퀴즈 내용 정리

CSAPP 책 11.3장에서는 프로그래머 입장에서 필요한 깊이 만큼의 TCP, UDP, HTTP 지식만을 다룬다.

응용 레벨에서 이 네트워크 프로토콜들을 어떻게 사용하는지(시스템 콜, 소켓 API가 어떻게 동작하는지)에 초점을 맞춰서 공부해보자.

OSI 7 Layers

이 영상에 OSI 7 Layers에 대한 핵심이 잘 정리되어있다.

상위 계층이 하위 계층을 사용하는 구조. 따라서 상위 계층은 하위 계층이 하는 일을 몰라도 된다.

예를 들어 application layer는 애플리케이션 간의 통신을 어떤 프로토콜을 사용해서 구현할 건지만 정하면 되고, 실제로 애플리케이션 간에 데이터를 어떻게 주고 받는지에 대해서는 하위 계층에서 구현된 방법을 사용하기만 하면 됨

이미지 출처 : https://jakarta.telkomuniversity.ac.id/en/7-osi-layer-the-building-blocks-of-networking/

• application layer
  • 애플리케이션 목적에 맞는 통신 방법을 제공하는 계층
  • ex) http - 웹 페이지를 주고 받을 때, dns - 도메인을 ip주소로 변환하고싶을 때, smtp - 메일을 주고 받을 때, ftp - 파일을 업로드하고 다운로드받을 때
• presentation layer
  • 애플리케이션 간의 통신에서 메시지 포맷을 관리하는 계층
  • 데이터 형식, 인코딩, 암호화, 압축 등 받은 데이터에 어떤 처리를 해줘야 할지에 대해 관여
• session layer
  • 애플리케이션 간의 통신에서 세션을 관리
  • RPC(remote procedure call)
• transport layer
  • 애플리케이션 간의 통신을 담당하는 계층
  • 목적지 application까지 데이터를 전송할 때 안정적이고 신뢰할 수 있는 방법으로 보낼지, 필수 기능만 제공할지 결정
  • TCP/UDP
• network layer
  • host에서 host까지 가는 데 가장 최적의 경로가 무엇인지 결정하는 계층
  • host 간의 통신 담당 (IP주소 기반 통신)
• data link layer
  • 직접적으로 연결된 node와 node간의 통신을 담당하는 계층
  • 장치 간의 통신 담당 (MAC주소 기반 통신)
  • ARP : IP 주소를 MAC 주소로 변환해주는 프로토콜
• physical layer

HTTP

• World Wide Web에서 데이터를 주고 받기 위해 쓰이는 기본적인 프로토콜
• Tim Berners-Lee가 1989년에 클라이언트-서버 간에 간단한 문서를 주고 받는 방법으로 처음 HTTP를 제안
• hypertext (페이지가 선형적으로 넘어가는 형식이 아니라 하이퍼 링크를 통해 비선형적으로 다른 문서나 정보에 즉시 접속할 수 있는 탐색 방식)가 포함된 문서를 주고 받을 때 쓰이는 프로토콜

더보기

(참고) World Wide Web(WWW)

• 1990년에 등장한 시스템으로, 전 세계에 널리 퍼진 거미줄(Web)이라는 단어 의미 그대로 인터넷 통신망에서 hyper text markup 언어로 작성하고, url로 위치를 지정하고, hyper text 전송 프로토콜로 데이터를 전송하는 정보 시스템이다. 이 과정을 돕는 프로그램이 웹 브라우저, 웹 서버이다.
• '인터넷'의 동의어로 여기는 사람이 많지만 인터넷은 TCP/IP 프로토콜로 구현된 통신망이고 World Wide Web은 인터넷 안에서 이미지와 문자를 전송하는 하이퍼텍스트 전송 프로토콜로 구현된 정보시스템이다.

출처: 위키피디아

HTTP 메시지

• 4개의 영역으로 구분 (시작 라인 - 헤더 - 공백 라인(CRLF) - 바디)

시작 라인	요청 메시지	GET	HTTP 메서드(GET/POST/PUT/DELETE) 서버가 수행해야 할 동작을 지정
		/search?q=hello&hl=ko	요청 대상 absolute path (/로 시작하는 절대 경로) + ? + 쿼리
		HTTP/1.1	HTTP version
	응답 메시지	200	HTTP status code request의 성공/실패 여부를 나타냄
		OK	상태 코드에 대해 사람이 이해할 수 있는 짧은 설명
헤더	Host: www.google.com	Host	field-name 대소문자 구분 X
		:	콜론 + OWS(띄어쓰기)
		www.google.com	field-value 대소문자 구분 O
바디	HTML 코드 이미지 영상 JSON ...		실제 전송할 데이터 Byte로 표현할 수 있는 모든 데이터 전송 가능

HTTP 상태코드

2xx (successful)	클라이언트의 요청을 성공적으로 처리
	200 OK	요청 성공
	201 Created	요청을 성공해서 새로운 리소스가 생성됨 location 헤더를 통해 방금 만든 리소스가 어떤 URL에 생성되었는지 알려줌 클라이언트는 해당 URL로 GET요청을 날려서 새로 만든 리소스를 바로 확인할 수 있음 RESTful API 규칙 중 '생성 결과를 명확히 알려라'라는 규칙을 만족시키는 부분
	202 Accepted	요청이 접수되었으나 처리가 완료되지 않음 (잘 사용되지 않음)
	204 No Content	서버가 요청을 성공적으로 수행했지만 응답 페이로드 본문에 보낼 데이터가 없음 ex) 웹 문서 편집기에서 save 버튼 save 버튼의 결과로 아무 내용이 없어도 된다. save 버튼을 눌러도 같은 화면을 유지해야 한다. 결과 내용이 없어도 204 메시지만으로 성공을 인식할 수 있다.
3xx (redirection)	클라이언트가 보낸 요청을 완료하기 위해 브라우저단에서 추가적인 작업이 필요하다고 판단해 클라이언트에게 다시 메시지를 보냄 ex) 웹 브라우저는 301 응답 결과 + locaion 헤더가 있으면 브라우저가 해당 URL로 자동 리다이렉트하여 해당 URL로 GET 요청을 보냄
4xx (client error)	클라이언트 요청의 잘못된 문법 등으로 서버가 요청을 처리할 수 없는 상황 오류의 원인이 클라이언트에게 있으므로 클라이언트가 똑같은 요청을 아무리 재시도해도 실패 따라서 클라이언트 측에서 요청 내용을 재검토하고 보내야 함
	400 Bad Request	클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음 요청 파라미터가 맞지 않는 경우(숫자를 문자로 보낸 경우 등) API 스펙이 맞지 않는 경우
	401 Unauthorized	클라이언트가 해당 리소스에 대한 인증이 필요함 로그인 시 본인이 누구인지 인증(Authentication)되지 않음
	403 Forbidden	서버가 요청을 이해했지만 승인을 거부함 인증 자격 증명이 있지만 접근 권한이 불충분함 예를 들어 admin 등급이 아닌 사용자가 로그인은 했지만 admin 등급의 리소스에 접근하는 경우
	404 Not Found	요청 리소스를 서버에서 찾을 수 없음 클라이언트가 권한이 부족한 리소스에 접근할 때 서버가 해당 리소스를 숨기고싶을 때

 

성공 시 200, 201까지만 사용하는 경우가 많음. 보통 어느 범위까지 쓸지 코드 컨벤션으로 정해둠

TCP (transmission control protocol)

• connection-oriented
  • 클라이언트가 connect()함수를 호출하고 서버가 accept()함수로 받아 연결 소켓이 하나 나올 때 그 과정 속에서 내부적으로 클라이언트-서버 간에 TCP 연결이 맺어진다.
  • TCP 연결이 맺어지면 클라이언트-서버 프로세스 간에 안정적으로 데이터를 주고받기 위한 논리적인 통신 통로가 형성되었다고 한다.
  • connection을 열어 3-way handshake로 연결을 맺고 데이터를 주고받은 후 4-way handshake로 connection을 닫고 연결을 끊는다. 이 과정을 connection oriented라고 부른다.
• socket (ip address + port number)
  • 클라이언트의 프로세스와 서버의 프로세스 사이에 데이터를 주고 받기 위해 인터넷 상에서 고유한 식별자가 필요하다.
  • <ip, port>로 인터넷에 존재하는 각 port를 유니크하게 식별하기 위한 주소를 만들어서 통신하기로 함 -> 이를 Socket이라고 부름
  • 즉 socket은 인터넷에서 각 포트를 유니크하게 식별하기 위한 주소
• 한 쌍의 socket은 TCP connection을 유니크하게 식별한다
  • <src socket, dest socket> 즉 <src IP, src Port, dest IP, dest Port> 값이 TCP에서 정의하는 connection 식별자
• 하나의 socket은 여러 TCP connection에 사용될 수 있다
  • 다른 식별자를 가진 여러 socket들이 하나의 socket과 동시에 연결될 수 있음

UDP (user datagram protocol)

• connectionless : 연결을 맺지 않고 바로 데이터를 주고 받는다.
• IP 프로토콜만 쓰는 것과 다를 바 없을 정도로 unreliable함
• 원래 TCP에서 port를 식별하려고 socket 개념이 등장했는데 UDP에서도 port번호로 호스트의 프로세스를 식별해야 하므로 자연스럽게 socket 개념을 쓰기 시작함
• UDP는 <protocol, IP, Port>로 유니크하게 프로세스를 식별하게 됨 -> socket개념이 UDP까지 확장되었으므로 protocol 정보가 추가되었음

네트워크 관점에서 TCP의 특징

• 연결 지향형(connection-oriented)
  • 클라이언트가 connect()를 호출하고 서버가 accept()로 받을 때 그 과정에서 3-way-handshaking이 일어난다.
• 1대1 연결(point-to-point)
  • 하나의 TCP connection은 하나의 sender와 하나의 receiver 간의 연결이다.
  • cf) UDP는 연결이라는 개념 자체가 없지만 어쨌든 차이점은 클라이언트 마다 커넥션이 맺어지는 게 아님. 누구한테 보낼지에 대한 정보만 필요함
• 신뢰성 있는 전송(reliable)
  • 통신에서의 reliable은 믿을만한 데이터인지 확인하는 안전 보장(security)개념이 아니라 데이터가 목적지의 transport layer까지 잘 전송되었는지 확인 가능하다는 의미
  • Stop and Wait, GBN(Go-Back-N), SR(Selective Repeat) 등의 프로토콜을 사용해 reliable한 패킷 데이터 교환
    • https://ddongwon.tistory.com/81 여기에 관련 프로토콜이 잘 정리되어있으니 궁금하면 읽어보기
      - 패킷이 중간에 사라지거나 순서가 바뀌었을 때 어떻게 처리할 건지에 관한 규칙
  • 참고로 Stop and Wait은 ACK이 올 때까지 기다리는 프로토콜이고 pipelining은 ACK이 올 때까지 기다리지 않고
• 데이터 전송 흐름을 제어(flow control)
  • 성능 차이가 많이 나는 두 기기 사이의 전송이라면 발신자는 수신자가 받을 수 있는 정도까지만 데이터를 전송
• 혼잡 제어(congestion control)
  • 네트워크의 경로가 혼잡할 때 발신자는 보내는 속도를 조절
• 수신 확인 및 재전송(acknowledgement and retransmissions)
  • 수신자가 수신확인 응답(ACK : acknowlegement) 메시지를 발신지에 돌려보냄
  • 발신자는 패킷을 보낼 때 타이머를 시작하여 ACK가 도착하기 전에 타이머가 만료되면 패킷을 재전송
• 데이터 전송 순서 보장(in-order data transfer)
  • 네트워크의 높은 지연으로 인해 재전송될 경우 패킷 중복이 발생할 수 있음
  • 따라서 일반적으로 TCP는 패킷에 순서 번호를 지정하여 수신 측이 이전에 도착한 순서 번호가 무엇인지 기억할 수 있도록 함
  • 패킷 순서가 맞아야 application layer로 데이터를 전달함
• 4-way handshaking로 연결 끊기

네트워크 관점에서 UDP의 특징

• 비연결 지향형 서비스 (connectionless)
• 신뢰성 없는 전송 (unreliable data transfer)
• 데이터 전송 흐름 제어 x (no flow control)
• 혼잡 제어 x (no congestion control)
• 그럼 UDP는 어디에 쓰이나?
  • 처리 속도가 빠르고 구현이 간단해서 실시간성 (realtime)이 중요할 때 사용한다. ex) broadcasting, multicasting

TCP와 UDP 비교

ref

https://youtu.be/X73Jl2nsqiE?si=ufX3KUsNDk_jTCum

https://youtu.be/WwseO8l8rZc?si=8P78SnWIKjLAARci https://www.youtube.com/watch?v=6l7xP7AnB64&t=704s