(S3W4) TIL 60일차 220425 (네트워크 심화)

오늘의 학습목표

• HTTP 기반 네트워크 흐름에 대해 이해할 수 있다.
• TCP/IP 기반 네트워크 흐름에 대해 이해할 수 있다.
  • TCP/IP 패킷이 왜 필요한 지 설명할 수 있다.
  • TCP와 UDP의 차이에 대해 설명할 수 있다.
• HTTP 기본 동작과 특징에 대해 이해할 수 있다.
  • 상태유지(Stateful)과 무상태(Stateless)의 개념에 대해 설명할 수 있다.
  • HTTP 메시지 구성에 대해 설명할 수 있다.
• HTTP 헤더의 역할에 대해 이해할 수 있다.
  • 표현, 콘텐츠 협상 등 다양한 헤더의 역할에 대해 알 수 있다.
• 캐시가 왜 필요한 지 알 수 있다.
  • 브라우저 캐시, 프록시 캐시에 대해 설명할 수 있다.
  • 조건부 요청, 캐시 무효화 방법 등을 사용할 수 있다.

 

학습내용

IP와 IP Packet

IP는 지정한 IP 주소에 패킷(Packet)이라는 통신 단위로 데이터를 전달합니다.

Packet

IP 패킷에서 패킷은 pack와 bucket이 합쳐진 단어로 소포로 비유할 수 있습니다.

소포를 데이터 통신에 적용한 것처럼, 우체국 송장처럼 전송 데이터를 무사히 전송하기 위해,

출발지 IP, 목적지 IP와 같은 정보가 포함되어 있습니다.

클라이언트에서 서버로 패킷 전달

패킷 단위로 전송을 하면 노드들은 목적지 IP에 도착하기 위해 서로 데이터를 전달합니다.

복잡한 인터넷 망 사이에서도 정확한 목적지로 패킷을 전송할 수 있습니다.

서버에서 클라이언트로 패킷 전달

서버에서 무사히 데이터를 전송받는다면 서버도 이에 대한 응답을 돌려줘야 합니다.

서버 역시 IP 패킷을 이용해 클라이언트에 응답을 전달합니다.

IP 프로토콜 한계

비연결성: 패킷을 받을 대상이 없거나 서비스 불능 상태여도 데이터 전송

비신뢰성: 중간에 패킷이 사라질 수 있고, 패킷의 순서를 보장할 수 없음

IP 프로토콜 한계 보완

IP 프로토콜 보다 더 높은 계층에 TCP 프로토콜이 존재하기 때문에 IP 프로토콜의 한계를 보완할 수 있습니다.

TCP 특징 / TCP로 IP 프로토콜 한계 보완

1. TCP 3 way handshake

1. 먼저 클라이언트는 서버에 요청하는 SYN(Synchronize) 패킷을 보냅니다.
2. 서버는 SYN 요청을 받고 클라이언트에게 요청을 수락한다는 ACK 와 SYN이 설정된 패킷을 발송후, 
3. 클라이언트가 서버에게 ACK(Acknowledgement)를 보내면 연결이 성립되며 데이터를 전송할 수 있습니다.

만약 서버가 꺼져있다면 클라이언트가 SYN을 보내고, 서버에서 응답이 없기 때문에 데이터를 보내지 않습니다.

2. 데이터 전달 보증

TCP는 데이터 전송이 성공이라면 이에 대한 응답을 돌려주기 때문에 IP 패킷의 한계인 비연결성을 보완할 수 있습니다.

3. 순서 보장

만약 패킷이 순서대로 도착하지 않는다면 TCP 세그먼트에 있는 정보를 토대로 다시 패킷 전송을 요청할 수 있습니다.

UDP 특징 / UDP로 IP 프로토콜 한계 보완

UDP는 IP 프로토콜에 PORT, 체크섬 필드 정보만 추가된 단순한 프로토콜입니다.

TCP 특징과 비교해보면 신뢰성은 낮지만 TCP와 비교해 빠른 속도를 보장합니다.

TCP보다 커스터마이징이 가능하다는 장점이 있습니다.

TCP vs UDP

HTTP

HTTP/1.1, HTTP/2는 TCP 기반이며,

HTTP/3은 UDP 기반 프로토콜입니다.

HTTP 특징

1. 클라이언트 서버 구조

클라이언트가 서버에 요청을 보내면 서버는 그에 대한 응답을 보내는 클라이언트 서버 구조로 되어있습니다.

2. 무상태 프로토콜 / Stateless

HTTP에서는 서버가 클라이언트의 상태를 보존하지 않는 무상태 프로토콜입니다.

장점: 서버 확장성 높음

단점: 클라이언트가 추가 데이터 전송

무상태의 실무 한계

3. 비 연결성 / Connectionless

HTTP는 기본이 연결을 유지하지 않는 모델입니다. (최소한의 자원으로 서버 유지)

비 연결성을 가지는 HTTP에서는 실제로 요청을 주고받을 때만 연결을 유지하고 응답을 주고 나면 TCP/IP 연결을 끊습니다.

TCP/IP의 경우 기본적으로 연결을 유지합니다. (연결을 유지하는 서버의 자원이 계속 소모됩니다)

 

 HTTP 헤더와 바디

HTTP 헤더는 HTTP 전송에 필요한 모든 부가정보를 담기 위해 사용됩니다.

표현 헤더

요청(Request), 응답(Responses) 둘 다 사용

• Content-Type: 표현 데이터의 형식
• Content-Encoding: 표현 데이터의 압축 방식 // Content-Encoding: gzip
• Content-Language: 표현 데이터의 자연 언어 // Content-Language: ko
• Content-Length: 표현 데이터의 길이

콘텐츠 협상 헤더

요청(Request)시에만 사용

• Accept: 클라이언트가 선호하는 미디어 타입 전달
• Accept-Charset: 클라이언트가 선호하는 문자 인코딩
• Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
• Accept-Language: 클라이언트가 선호하는 자연 언어 // Quality Values(q)값 사용, 0~1 클수록 높은 우선 순위

요청(Request)에서 사용되는 헤더

From: 유저 에이전트의 이메일 정보

• 일반적으로 잘 사용하지 않음
• 검색 엔진에서 주로 사용
• 요청에서 사용

Referer: 이전 웹 페이지 주소

• 현재 요청된 페이지의 이전 웹 페이지 주소
• A → B로 이동하는 경우 B를 요청할 때 Referer: A를 포함해서 요청
• Referer를 사용하면 유입경로 수집 가능
• 요청에서 사용
• referer는 단어 referrer의 오탈자이지만 스펙으로 굳어짐

User-Agent: 유저 에이전트 애플리케이션 정보

• 클라이언트의 애플리케이션 정보(웹 브라우저 정보, 등등)
• 통계 정보
• 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
• 요청에서 사용
• e.g.
  • user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/ 537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36

Host: 요청한 호스트 정보(도메인)

• 요청에서 사용
• 필수 헤더
• 하나의 서버가 여러 도메인을 처리해야 할 때 호스트 정보를 명시하기 위해 사용
• 하나의 IP 주소에 여러 도메인이 적용되어 있을 때 호스트 정보를 명시하기 위해 사용[그림] HTTP HOST 헤더 비교

Origin: 서버로 POST 요청을 보낼 때, 요청을 시작한 주소를 나타냄

• 여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 발생한다.
• 응답 헤더의 Access-Control-Allow-Origin와 관련

Authorization: 인증 토큰(e.g. JWT)을 서버로 보낼 때 사용하는 헤더

• “토큰의 종류(e.g. Basic) + 실제 토큰 문자”를 전송
• e.g.
  • Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

응답(Response)에서 사용되는 헤더

Server: 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보

• 응답에서 사용
• e.g.
  • Server: Apache/2.2.22 (Debian)
  • Server: nginx

Date: 메시지가 발생한 날짜와 시간

• 응답에서 사용
• e.g.
  • Date: Tue, 15 Nov 1994 08:12:31 GMT

Location: 페이지 리디렉션

• 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 리다이렉트(자동 이동)
• 201(Created): Location 값은 요청에 의해 생성된 리소스 URI
• 3xx(Redirection): Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를 가리킴

Allow: 허용 가능한 HTTP 메서드

• 405(Method Not Allowed)에서 응답에 포함
• e.g.
  • Allow: GET, HEAD, PUT

Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

• 503(Service Unavailable): 서비스가 언제까지 불능인지 알려줄 수 있음
• e.g.
  • Retry-After: Fri, 31 Dec 2020 23:59:59 GMT(날짜 표기)
  • Retry-After: 120(초 단위 표기)

프록시 캐시 (Proxy Cache)

미국의 원 서버로부터 데이터를 가져오고싶지만, 너무 오래걸릴때

한국에 프록시 캐시서버를 두고 프록시 캐시서버를 통해 자료를 가져온다면,

여러 사람이 찾은 자료일수록 이미 캐시에 등록되어 있기에 빠른 속도로 자료를 가져올 수있습니다.

 

오늘의 회고