TIL-55, 네트워크
인터넷은 어떻게 작동할까??
엄청나게 복잡한 인터넷 망 속에 있는
엄청나게 많은 노드(하나의 서버 컴퓨터)들을 지나 어떻게
클라이언트와 서버의 통신이 가능한걸까?
패킷 (Packet)
각각의 PC에 IP(Internet Protocol)이라는 주소를 부여하고,
패킷(Packet)이라는 통신 단위로 지정한 IP주소에 전달한다.
마치 소포와 같다고 생각하면 되는데, 패킷 안에는 출발지 IP, 목적지 IP 등 전송을 위한 정보가 들어있고,
전송하려는 데이터도 들어있다.
이렇게 패킷 단위로 전송을 해 정확한 목적지로 데이터를 전달할 수 있다.
클라이언트로부터 데이터를 받으면 서버 역시 응답을 돌려줘야 하는데,
이 때도 IP 패킷을 이용해 응답을 전달한다.
하지만 IP 프로토콜의 한계도 존재한다.
- 비연결성
- 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
- 비신뢰성
- 중간에 패킷이 사라질 수 있음
- 패킷의 순서를 보장할 수 없음
TCP / UDP
패킷의 한계를 보완하기 위해 네트워크 계층 구조를 이용한다
네트워크 프로토콜은 위와 같이 OSI 7계층, TCP / IP 4계층으로 나눌 수 있다.
IP 프로토콜보다 높은 계층에 TCP 프로토콜이 존재하기 때문에, 위에서 다룬 IP 프로토콜의 한계를 보완할 수 있다.
TCP 세그먼트에는 IP 패킷의 출발지 IP, 목적지 IP 정보를 보완할 수 있는
출발지 PORT, 목작지 PORT, 전송 제어, 순서, 검증 정보등을 포함하고 있다.
TCP 전송 제어 프로토콜 (Transmission Control Protocol) 의 특징
- 같은 계층에 속한 UDP에 비해 상대적으로 신뢰할 수 있는 프로토콜이다
- 연결 지향 - TCP 3 way handshake (가상 연결) → 장치들 사이에 논리적인 접속을 성립하기 위한 방법 데이터의 전송이 성공적으로 이루어져야 응답을 돌려주기 때문에 IP패킷의 비연결성을 보완.
- 데이터 전달 보증
- 순서 보장 → 패킷이 순서대로 도착하지 않으면 TCP 세그먼트의 정보를 토대로 패킷 재전송을 요청한다
- 신뢰할 수 있는 프로토콜
UDP 사용자 데이터그램 프로토콜 (User Datagram Protocol) 의 특징
- 하얀 도화지에 비유된다 (기능이 거의 없음)
- 비 연결지향 - TCP 3 way handshake X
- 데이터 전달을 보증하지 않는다
- 순서를 보장하지 않는다
- 데이터 전달 및 순서가 보장되지 않지만 단순하고 빠르다
- 신뢰성보다는 연속성이 중요한 서비스(실시간 스트리밍 등)에 자주 사용된다.
UDP는 IP프로토콜에 PORT, 체크섬 필드 정보만 추가된 단순한 프로토콜이다.
TCP보다 신뢰성은 낮지만 3way handshake를 사용하지 않기 때문에 비교적 빠른 속도를 보장한다.
UDP는 필요한 기능만 들어있는 가벼운 프로그램, TCP는 좋은 기능은 다 들어있는 무거운 프로그램으로 생각하자.
HTTP
HTTP의 특징
- 클라이언트 서버 구조
- 무상태 프로토콜(Stateless), 비연결성(Connectionless) → 무상태성, 서버가 클라이언트의 상태를 보존하지 않는다. 장점: 서버 확장성이 높음 (스케일 아웃) 단점: 클라이언트가 추가 데이터 전송
- HTTP 메시지
- 단순함, 확장 가능
- 빠른 속도의 응답
클라이언트가 요청(req)을 보내면, 서버는 응답(res)를 보내는 구조.
무상태와 상태
상태 유지는, 어떤 서버에 상태를 보관하고, 클라이언트는 그 서버에만 요청을 보내야 한다. (서버에 데이터를 보관을 해놨기 때문에) 그래서, 해당 데이터가 보관된 서버가 오류가 나면, 서버에 보관되던 데이터가 날아가기 때문에 처음부터 다시 서버에 요청을 해야한다. 하지만, 무상태 프로토콜이라면 서버에 요청할 때 이미 데이터를 전부 담아서 보내므로 아무 서버에 요청해도 되고, 응답 서버를 쉽게 바꿀 수 있기 때문에 무한한 서버 증설이 가능하다.
무상태의 한계
- 모든 것을 무상태로 설계할 수 있는 경우도 있고 없는 경우도 있다.
- 무상태 → 로그인이 필요없는 단순한 서비스 소개 화면
- 상태 → 로그인
- 로그인한 사용자의 경우 로그인했다는 상태를 서버에 유지 (브라우저 쿠키, 서버 세션)
- 상태 유지는 최소한만 사용
TCP/IP의 경우 기본적으로 연결을 유지하기 때문에 요청을 보내지 않더라도 연결을 유지하는 서버의 자원이 계속 소모된다.
하지만 비연결성을 가지는 HTTP는 요청을 주고 받을때만 연결을 유지하고, 응답을 주고나면
TCP/IP 연결을 끊는다. 때문에 최소한의 자원으로 서버 유지를 가능하게 한다.
HTTP 헤더와 바디
HTTP의 메시지는 헤더와 바디로 구분한다.
바디에는 메시지 본문을 통해 표현 데이터를 전달한다.
이 때 데이터를 실어 나르는 메시지 본문을 페이로드(Payload)라고 한다.
표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공한다.
헤더의 형식은
field-name : field-value 이와 같다.
(ex, Content-Type : text/html;charset=UTF-8 )
HTTP 헤더는 HTTP 전송에 필요한 모든 부가정보를 담기 위해 사용한다.
예를 들어, 메시지 바디의 내용, 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보 등등이다.
!! 필요시 임의의 헤더 추가가 가능하다. !!
Content-Type→ 표현 데이터의 형식- Text/html; charset=utf-8
- application/json
- image/png
Content-Encoding→ 표현 데이터의 압축 방식- gzip
- deflate
- identify
Content-Language→ 표현 데이터의 자연 언어- ko
- en
- en-US
Content-Length→ 표현 데이터의 길이- 숫자
표현 헤더는 요청, 응답 둘 다 사용한다.
캐시
캐시는 컴퓨터 과학에서 데이터나 값을 미리 복사해 놓는 임시 장소를 가리킨다.
만약 클라이언트가 서버에 jpg파일을 요청하고, 서버는 그 jpg파일을 다운로드해 클라이언트에게 응답한다.
다시 클라이언트가 똑같은 jpg파일을 요청하면, 파일의 변경사항이 없는데도 불구하고 재 다운로드를 해야한다.
다운로드를 계속 하므로, 네트워크를 계속 사용하게 돼서 비용이 발생하고, 브라우저 로딩 속도가 느려진다.
때문에 캐시에 데이터를 미리 복사해놓고 계산이나 접근 시간 없이 빠른 속도로 데이터에 접근할 수 있다.
cache-control 속성을 통해 유효시간을 설정할 수 있다.
Cache-Control: max-age=60 으로 설정하면 60초 동안 유효하다.
60초가 지난 뒤 요청을 하면, 다시 다운로드를 하고 60초간 유효한 캐시 이미지를 응답받는다.
만약, 캐시 유효기간은 지났지만 데이터의 변경이 없기 때문에 그대로 사용해도 되는 상황이라면?
이를 검증하고 재사용한다.
검증 헤더인 Last Modified는 데이터가 마지막으로 수정된 시간 정보를 헤더에 포함하고,
응답 결과를 캐시에 저장할 때 데이터 최종 수정일이 저장된다.
해당 최종 수정일과 비교해서 데이터가 수정이 안되었을 경우에 응답 메세지에 이를 담아서 알려준다.
변경된 데이터가 없기 때문에 바디가 빠지고, 아주 적은 용량을 가진 헤더만 전송된다.