Aug 1, 2021 - TCP/IP, UDP, Port, DNS, URI, HTTP1.1, 2,3, Stateless & Stateful, 비연결성

*8월1일

-HTTP 본격 진입 전, 여러 개념에 대해 정리 해보자.

 

*인터넷 네트워크, IP protocol

-클라이언트 <-> 해저케이블, 위성, 수 많은 노드들..... <-> 서버

-from 2.3.50.12 to 30.50.100.2로 req, res하며 client & server packet으로 데이터 전달

-IP의 경우 비연결성, 비신뢰성, 프로그램 구분 불가 등으로 한계가 있음.

 

*TCP

-TCP가 IP의 한계를 해결 해줌. Transmission Control Protocol로 데이터 전달 보증, 순서보장, 연결 지향(3way handshake) 등을 특징으로 함. IP의 한계를 TCP/IP로 보완해줌.

-IP와 달리 TCP는 port, 순서, 검증정보가 존재함.

-연결지향이란, 클라이언트와 서버 모두 syn -> syn+ack -> ack 식으로 실제 서로 연결 되는지 먼저 확인함.

-데이터 전달 보증이란, req, res로 데이터 전송 응답에 대한 확인

-순서 보장이란, 순서에 맞지 않게 전송되면 잘못 전송된 순서부터 다시 보내는 식으로 서버에서 요청

 

*UDP

-TCP와 같은 계층으로 user datagram protocol임. TCP와 달리 연결지향, 데이터 전달 보증, 순서 보장 모두 없는 거의 백지 상태. IP와 비교 시 port가 있다 정도의 차이. HTTP2,3에서 각광 받는 중이라고 함.

 

*Port

-동시에 여러 작업을 소화 할 때 어디에서 날아온 패킷인지 구분하기 위함. TCP/UDP 모두 출발지 port, 목적지 port가 있음.

-0~65535까지 할당 가능하며, 0~1023까지는 커스텀해서 사용하지 않는게 좋음.

 

*DNS

-Domain Name System으로 도메인 네임 받은 후, IP로 변환해서 클라이언트 연결 시켜줌.

 

*URI, URL, URN

-URI가 가장 상위 개념으로 Uniform resource identifier, 특정한 자원 자체를 식별함. URL의 경우, 특정 자원의 위치가 매핑된 형태. URN은 특정 자원의 이름.

 

https://www.ki.co.kr/index  //URI만 될 수 있음.

https://www.ki.co.kr/index.html  //URL과 URI 모두 될 수 있음.

 

*프로토콜//호스트:포트/패스?쿼리=파람&쿼리=파람

 

-프로토콜은 http, https, ftp 등, 호스트는 ip나 도메인명, path는 계층적 구조 경로로 c/asia, europe등등, query는 key & value 형태, fragment는 #mid #top과 같이 특정한 html 내 위치 경로

 

*HTTP
-모든것이 HTTP -> 이미지,음성,영상,파일,JSON,XML 등 모든 것 전송 가능하며, 서버 간의 데이터를 주고 받을 때도 대부분 HTTP 사용! 즉, 지금은 HTTP 시대.
-HTTP 1.1이나 2와 같은 경우에는 TCP 기반으로 동작 / HTTP 3은 UDP 기반으로 동작함.
-현재 주류는 1.1이지만 2,3도 점점 증가 추세

-클라이언트 서버 구조, stateless 프로토콜 지향, 비연결성, 단순하며 확장 가능

 

1)클라이언트-서버 구조
-Request & response 구조
-비즈니스로직과 데이터는 다 서버에 밀어넣고, 클라이언트에서는 UI, UX만 집중함; 따라서 양쪽이 독립적으로 진화 할 수 있음.

2)무상태프로토콜 : stateless
-서버가 클라이언트의 상태를 보존하지 않음. 따라서 서버 확장성이 높다. 다만 클라이언트가 추가 데이터를 전송 해야한다.
-예를들면 특정한 제품을 구매할 때, 클라이언트 측에서 "#AB3021 제품을 / 2개 / 신용카드로 구매하겠습니다"와 같이 대응 서버가 바뀌어도 모든 정보를 전달하는 구조

-따라서 stateless를 사용하여 갑작스럽게 증가하는 클라이언트의 요청에 대응 가능함 -> 무한한 서버 증설 가능

-stateless의 경우 중간에 기존 대응 서버가 장애가 발생해도, 자연스럽게 다른 서버와 req, res 진행함. 따라서 stateless는 scale out 즉 수평 확장에 유리함. 같은 기능을 하는 서버군을 확 늘려버릴 수 있음.

-하지만 실무적으로 적용될 수 없는 경우도 있음. 예를들면 로그인의 경우 서버에서 계속해서 유지 해줘야하기 때문에, stateful을 사용할 수 밖에 없음(stateful은 꼭 필요한 경우에만 최소한 사용해야함; 대부분 stateless로 설계 하는게 맞음)

 

3)비연결성 connectionless
-연결성의 경우, 계속해서 연결 유지해야하기에 서버의 자원을 지속적으로 소모함. 반면에 비연결성의 경우 req/res 처리 후 바로 연결을 끊음. 그만큼 자원 세이브 가능.
-HTTP는 기본적으로 비연결성 기반. 일반적으로 초단위로 응답. 1시간 동안 수천명이 서비스를 사용해도, 실제 서버에서 동시에 처리하는 요청은 수십개 이하로 매우 작음. 왜냐하면 클라이언트에서 계속해서 새로운 메뉴/검색 버튼을 누르지 않기에 서버 입장에서는 자원을 효율적으로 사용할 수 있음.

 

*비연결성의 한계
-기본적으로 TCP/IP 연결을 계속해서 새로 맺어야 함. 즉 3 way handshake 시간이 계속 추가됨. 또한 HTML 뿐만 아니라 JS, CSS, 추가 이미지 등 여러 자원이 다운로드 됨...
-따라서 요즘은 HTTP 지속연결(persistent connections)로 문제 해결을 함. http2,3에서 더 최적화 되어 있음.

 

*stateless를 기억하자..
-서버 개발자들이 어려워하는 업무; 같은 시간에 딱 맞추어 발생하는 대용량 트래픽; 선착순 이벤트, 명절 KTX, 수강 신청 등.
-그럼에도 불구하고 최대한 stateless하게 설계하는게 중요하다.
-상기 언급된 케이스에 대한 해결은 일반적으로, 로그인이 필요없는 정적 페이지를 하나 뿌림; 사람들이 구경하고 볼 수 있는 정도의 페이지. 그 후에, 확인 후 이벤트 참여 버튼을 누를 수 있게 처리 해놓음.

 

*HTTP, HTTPS 차이

-HTTP는 80포트 사용, 암호화되지 않은 평문 데이터를 전송하는 프로토콜로, 비밀번호나 주민번호를 주고 받으면 제 3자가 조회 가능.

-HTTPS(secure) 데이터 암호화가 추가된 프로토콜, 443번 포트를 사용하며 제3자가 정보를 볼 수 없도록 공개키 암호화 지원. 암호화 복호화 과정이 필요하기 때문에 HTTP보다 속도가 느리지만 오늘날에는 거의 차이를 못느끼는 수준임

 

*스케일아웃 / 스케일업의 차이

-스케일 아웃은 서버를 여러대 추가하여 시스템을 확장하는 방법. 1의 처리 능력을 가진 동일한 서버 여러대 증설. 데이터의 변화가 적은 웹서버에 적합한 방법.

-스케일업은 CPU나 RAM등을 추가하거나 고성능의 부품, 서버로 교환하는 방법을 의미함. DB서버에 적합함.