IP
클라이언트와 서버가 통신하는 방법
출발지(클라이언트)에서 목적지(서버)까지 데이터가 전달되기 위해선 규칙이 필요
IP 주소를 컴퓨터(클라,서버)에 부여하고 이를 이용해 통신
IP는 지정한 IP 주소에 패킷이라는 통신 단위로 데이터 전달
패킷 : pack + bucket의 합성어, 소포로 비유
IP 패킷은 이를 데이터 통신에 적용한 것 출발지IP,목적지IP 등의 정보가 포함되어 있음
패킷 단위로 전송 시 노드들은 목적이 IP에 도달하기 위해 서로 데이터 전달 이를 통해 전송가능
서버에서 데이터를 전송받았다면 서버 역시 IP 패킷을 이용하여 클라이언트에게 응답하여 전달
IP 프로토콜의 한계
- 비연결성
- 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
패킷을 받을 대상이 없거나 서비스 불능상태여도 클라이언트가 서버의 상태 파악불가능 -> 패킷을 그대로 전송
- 비신뢰성
- 중간에 패킷이 사라질 수 있음
- 패킷의 순서를 보장할 수 없음
중간에 있던 서버가 데이터를 전달하던 중 장애가 생겨 패킷이 중간에 소실되더라도 클라이언트가 파악할 방법이 없음
전달 데이터 용량이 클 경우 이를 패킷 단위로 나눠 데이터를 전달 -> 서로다른 노드를 통해 전달 될 수 있음 -> 클라이언트가 의도하지 않은 순서로 서버에 패킷 도착할 가능성 있음
이러한 한계를 보완하기 위해 존재하는 것이 있음 먼저 OSI 7 계층과 TCP/IP 4 계층을 알아야함
https://hahahoho5915.tistory.com/15
위의 사이트를 보면 TCP/IP 계층에 대해서 더 자세하게 알 수 있음
TCP 프로토콜이 IP 프로토콜보다 높은 곳에 존재하고 있기 때문에 IP 프로토콜의 한계를 보완할 수 있음
TCP 세그먼트에는 IP 패킷의 출발지 IP와 목적지 IP 정보를 보완할 수 있는 출발지PORT, 도착지PORT, 전송 제어, 순서, 검증 정보 등을 포함
TCP 특징
전송 제어 프로토콜(Transmission Control Protocol)
-
연결 지향 - TCP 3way handshake(가상 연결)
-
데이터 전달 보증
-
순서 보장
-
신뢰할 수 있는 프로토콜
-
연결 지향 - TCP 3way handshake(가상 연결)
연결방식
1. 클라이언트가 서버에 SYN 패킷 전송 (SYN은 Syncronize)
2. 서버는 SYN요청을 받고 클라이언트에게 요청을 수락한다는 ACK와 SYN가 설정된 패킷을 발송 후 클라이언트가 다시 ACK로 응답하는 것을 대기 (ACK는 Acknowledgment)
3. 클라이언트가 서버에게 ACK를 보내면 이후 연결 성립 데이터 전송가능
만약 서버가 꺼져있다면 서버에서 응답이 없기 때문에 데이터를 보내지 않음
현재는 3번 클라이언트가 ACK를 보낼 때 데이터를 함께 보내기도 함
- 데이터 전달 보증
TCP는 데이터 전송이 성공적으로 이루어진다면 이에 대한 응답을 돌려주기 때문에 IP 패킷의 한계인 비연결성을 보완가능
- 순서 보장
만약 패킷이 순서대로 도착하지 않는다면 TCP 세그먼트에 있는 정보를 토대로 다시 패킷 전송을 요청할 수 있음 -> IP 패킷의 한계인 비신뢰성(순서를 보장하지 않음)을 보완
UDP특징
사용자 데이터그램 프로토콜(User Datagram Protocol)
- 하얀 도화지에 비유(기능이 거의없음)
- 비 연결지향 - TCP 3way handshake X
- 데이터 전달 보증 X
- 순서 보장 X
- 데이터 전달 및 순서가 보장되지 않는 대신 단순하고 빠름
- 신뢰성보다 연속성이 중요한 서비스(실시간스트리밍등)에 자주사용
| TCP | UDP |
|---|---|
| 연결지향형 프로토콜 | 비 연결지향형 프로토콜 |
| 전송 순서 보장 | 전송 순서 보장X |
| 데이터 수신 여부 확인 O | 데이터 수신 여부 확인 X |
| 신뢰성 높지만 속도 느림 | 신뢰성 낮지만 속도 빠름 |
여담으로 HTTP/3에서는 기존 TCP 가 아닌 UDP 를 이용한 방식을 차용했는데 그 설명에 대한 자세한 내용이 담긴 블로그가 있어서 작성함
https://evan-moon.github.io/2019/10/08/what-is-http3/
위의 내용이 맞는 내용이지만 UDP의 특징중 하얀 도화지 즉 기능이 거의 없단 것에 중점을 둬서 기능이 없는게 아니라 기능을 채워 넣을 수 있는 것같다.
HTTP
HTTP 특징
-
클라이언트 서버 구조
-
무상태 프로토콜(Stateless), 비연결성(Connectionless)
-
HTTP 메세지
-
단순함, 확장 가능
-
클라이언트 서버구조
Request Response 구조
클라이언트는 서버에 요청을 보낸 뒤 응답 대기
서버가 요청에 대한 결과를 만들어 응답
- 무상태 프로토콜(Stateless), 비연결성(Connectionless)
서버가 클라이언트의 상태를 보존하지 않음
장점: 서버 확장성이 높음(스케일 아웃)
단점: 클라이언트가 추가 데이터 전송
- 상태유지 VS 무상태
상태 유지: 중간에 서버가 바뀌면 안됨(서버가 바뀔 때마다 상태 정보를 다른 서버에게 미리 알려줘야함)
무상태: 중간에 다른 서버로 바뀌어도 됨 -> 요청이 갑자기 증가해도 서버를 많이 추가할 수 있음
무상태는 응답 서버를 쉽게 바꿀 수 있음(무한한 서버증설 가능)
1번 서버에 문제가 생겨도 클라이언트에 상태가 들어있기 때문에 2,3번 서버로 빠르게 옮길 수 있음
- 무상태의 한계
로그인이 필요없는 단순한 서비스 소개 화면같은 경우엔 무상태로 설계할 수 있지만
로그인이 필요한 서비스라면 유저의 상태를 유지해야 되기 때문에 브라우저 쿠키, 서버 세션, 토큰등을 이용해 상태를 유지함
TCP/IP의 경우 기본적으로 연결을 유지 -> 요청을 보내지 않더라도 연결을 유지해야하므로 자원이 계속 소모
비 연결성을 가지는 HTTP의 경우 요청,응답을 주고받을 때만 연결을 유지 그 이외는 TCP/IP연결을 끊으므로써 자원 소모를 줄일 수 있음
- 비연결성
트래픽이 많지 않고, 빠른 응답을 제공할 수 있는 경우, 비연결성의 특징은 효율적으로 작동
하지만 트래픽이 많고, 큰 규모의 서비스를 운영할 때에는 비연결성은 한계가 들어남
한계
TCP/IP 연결을 새로 맺어야 함 -> TCP 3way handshake 시간 추가
웹 브라우저로 사이트 요청하면 HTML + CSS + JS 등 수 많은 자원이 함께 다운로드
-> 지금은 HTTP 지속연결로 문제 해결
HTTP 헤더
HTTP 메시지는 헤더와 바디로 구분 가능
HTTP 바디에서는 데이터 메시지 본문(Message body)을 통해서 표현(Representation) 데이터를 전달
데이터를 실어 나르는 부분 = 페이로드(Payload)
표현은 요청이나 응답에서 전달할 실제 데이터를 뜻하며 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공 -> 데이터 유형, 데이터 길이, 압축 정보 등
헤더 형식 <field-name>:<field-value> field-name의 경우 대소문자 구분 없음
표현 헤더
- Content-Type: 표현 데이터의 형식
- Content-Encoding: 표현 데이터의 압축 방식
- Content-Language: 표현 데이터의 자연 언어
- Content-Length: 표현 데이터의 길이
표현 헤더의 경우 요청과 등답 둘 다 사용
HTTP 주요헤더
From: 유저 에이전트의 이메일 정보
Referer: 이전 웹 페이지 주소
User Agent: 유저 에이전트 애플리케이션 정보
Server: 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보
Date: 메시지가 발생한 날짜와 시간
Host: 요청한 호스트 정보(도메인)
Location: 페이지 리디렉션
Allow: 허용 가능한 HTTP 메서드
Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
Authorization: 인증 토큰(e.g. JWT)을 서버로 보낼 때 사용하는 헤더
Origin: 서버로 POST 요청을 보낼 때, 요청을 시작한 주소를 나타냄
Access-Control-Allow-Origin: 요청을 보내는 주소와 받는 주소가 다르면 CORS 에러가 발생
주요 헤더의 경우는 urclass에서 추가 자료를 보는 것이 좋을 거 같다.
콘텐츠 협상
클라이언트가 선호하는 표현 요청
- Accept: 클라이언트가 선호하는 미디어 타입 전달
- Accept-Charset: 클라이언트가 선호하는 문자 인코딩
- Accept-Encoding: 클라이언트가 선호하는 압축 인코딩
- Accept-Language: 클라이언트가 선호하는 자연 언어
협상 헤더는 요청시에만 사용
GET / event
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7
Quality Values(q) 값 사용
0~1 클수록 높은 우선 순위
1이면 생략가능
위의 순위는 1번 ko-KR(1생략), 2번 ko(0.9) 3번 en-US(0.8) 4번 en(0.7)
순으로 높다.
만약 서버가 한국어를 언어로 가지고 있지 않고 영어와 스페인어를 가지고 있는데 스페인어가 기본 언어 일시
요청에 의해 스페인어가 아닌 영어로 응답이 온다.(한국어는 없으니 3순위인 영어가 나온다)
오늘은 실습이나 코딩보다는 네트워크에 대한 심화적인 내용에 대해서 공부했다.
이 문제의 경우 코딩할 경우에도 많이 쓰일 수 있지만 면접 질문으로도 많이 나온다고 하니 공부를 해야겠다.
