웹 개발 네트워크 지식

TCP / UDP

프로그램에서 메시지 전달 -> 라이브러리를 통해 OS로 전달

-> TCP 정보 생성 -> IP 패킷 생성

 

IP 패킷에는 출발 목적 전송 제어 순서 등 들어감

이로 인해 IP만 사용해서 해결 안됐던 문제들 해결

 

TCP 전송 제어 프로토콜

1. 연결 지향 : 3-way handshake를 통해 서버와 클라이언트 간의 세 번의 메시지를 주고 받음 이로 인해 연결이 된 것을 확인
   연결이 되면 데이터를 전송한다. 만약 서버가 꺼져 있다면 연결이 안된 것을 확인하고 메시지를 보내지 않음
   클라이언트(SYN) -> 서버(ACK,SYN) -> 클라이언트(ACK, 데이터 전송) -> 서버
2. 데이터 전달 보증 : 클라이언트(데이터 전송) -> 서버(데이터 받음) -> 클라이언트
3. 순서 보장 :  클라이언트에서 보낸 패킷의 순서가 다르면 서버가 순서가 다른 곳부터 다시 보내라고 한다.

 

이러한 특성들은 전송 제어, 순서, 검증 정보가 TCP 세그먼트 안에 들어가 있기에 가능하다.

그러므로 TCP는 신뢰할 수 있는 프로토콜이다.

 

UDP 

IP와 거의 같다. (IP는 포트가 없음)

다른 점이 있다면 포트가 추가된다. + 체크섬

만약 내 PC에서 여러 프로그램이 작동한다고 가정하면 내 IP로 수많은 패킷이 전송되게 되는데

이런 패킷들을 구분하고자 포트를 사용한다.

그럼 왜 쓸까? TCP와 비교하자면 속도 면에서 빠르다.

TCP의 경우 핸드쉐이킹 외 기타 작업들이 있기 때문에 시간을 많이 써서 느리다. 하지만 TCP를 건들자니 이미

수많은 네트워크는 TCP를 사용하기에 건들기가 어렵다. 그래서 TCP는 그대로 쓰고 UDP를 사용한다.

 

과거에는 UDP는 화질이 깨져도 되는 유튜브 같은 영상을 전송하는데 사용한다고 하지만 TCP를 사용한다

그럼 UDP는 어디에서 써야할까 최근에 나온 HTTP 3에서의 핸드쉐이킹을 없앤 최적화에 사용한다고 한다.

 

 

PORT / DNS

클라이언트가 여러 개의 서버와 통신을 할 때 여러 서버에서 패킷이 오게 되는데 그것을 구분하고자 포트를 사용한다.

보낼 때도 마찬가지로 사용한다.

 

TCP/IP 패킷 내에는 출발지 IP, PORT + 도착지 IP, PORT + 전송 데이터가 포함되어 있다.

 

포트 구분

0~65535까지 쓸 수 있고 0~1023은 잘 알려진 포트로 우리가 사용하는 프토로콜들이 사용하기에 사용하지 않는 것이 좋다.

 

 

 

DNS : 웹 주소는 IP로 접근한다. 하지만 외우기도 어렵고 IP가 바뀔 수도 있어 접근하기가 힘들다.

그것을 해결하고자 DNS(Domain Name System)을 사용한다.

도메인을 구매해서 산다음 등록을 하면 된다.

 

 

URI / URL

URI (Uniform Resource Identifier) : 자원을 식별하는 방법

URL ? URN ?

URL의 L은 Locator, URN의 N은 Name이다.

두 가지의 차이를 보면 HTTP:// … 의 경우 URL, 이름만 부여한 것은 URN이다.

하지만 URN은 구분하기 어렵기 때문에 거의 사용하지 않는다. 그래서 그냥 URL만 알면 될 것 같다.

 

URL = 프로토콜(http,https) + 호스트(www.naver.com) + 포트번호(80,443) + 경로(/search) + 쿼리 파라미터(q=hello)

 

포트 번호는 생략이 가능하다. 일반적으로 80,443

 

웹 브라우저 요청 흐름

먼저 DNS와 PORT 정보를 찾아낸다.

다음으로 HTTP 요청 메시지를 생성한다.

 

요청 메시지 : GET PATH + Query + Version + Host

 

그다음으로 소켓 라이브러리를 통해 OS로 데이터를 전달한다.

OS에서는 받은 요청 메시지를 통해 TCP / IP 패킷을 생성하고

생성한 정보들을  LAN 장비를 통해 서버로 전송한다.

 

HTTP

HTTP를 통해 Text, Image 등 거의 모든 형태의 데이터를 보냄 TCP프로토콜을 통해 직접적으로 데이터를 전송하는 경우는 거의 없다.

현재는 HTTP 1.1 버전을 사용하고 2,3은 성능 개선을 위주로 업그레이드 됐음

 

클라이언트 서버 구조

서버에는 로직, 데이터들을 집중 시키고 클라이언트에는 UI를 집중시켰다.

만약에 트래픽이 늘 경우에는 서버에만 신경쓰면 된다.

양쪽이 독립적으로 진행이 가능하다.

 

Stateful, Stateless

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

서버가 클라이언트의 상태를 보존하지 않는다

상태 유지의 경우 Context를 보존한다.

 

무상태를 하는 이유는 서버 증설하는데 이점이 있기 때문이다.

상태 보존을 할 경우에는 서버가 바뀔 경우 클라이언트가 요청하는 데이터가 없을 수 있다.

하지만 무상태의 경우는 클라이언트에서 그 데이터를 포함하고 있기 때문에 서버가 바뀌어도 장애없이 동작할 수 있다.

클라이언트가 갑자기 대폭 증가하였을 경우 무상태이면 서버 증설을 쉽게 할 수 있기 때문에 확장하는데 있어 유리하다.

 

하지만 로그인과 같은 경우 데이터를 들고 가야하기 때문에 상태 유지를 해야한다.

그리고 무상태의 경우 넘겨야하는 데이터가 많다.

 

비연결성

연결을 계속 하는 경우 서버에 동작이 없어도 계속 연결을 하고 있어야 한다.

연결을 유지 않는 경우는 요청이 끝나면 바로 연결이 끊긴다.

 

비연결로 하는 경우에는 서버가 유지하는 자원을 최소화할 수 있다.

HTTP는 기본적으로 연결을 유지하지 않는 모델이다.

대신 단점이 있는데 연결을 끊다보니 다른 페이지를 넣어가면 다시 핸드 쉐이크를 해야한다.

또한 HTML 뿐만 아니라 css.js 등 다양한 리소스들을 다시 다운 받아야 한다.

 

그래서 HTTP는 지속 연결을 사용한다. 

HTTP2, HTTP3는 더욱 더 빠른 속도로 할 수 있다.

 

Stateless 관련 업무 : 선착순 이벤트와 같은 고정 시간에 대용량 트래픽이 발생하는 경우