네트워크

Heechang Jeong·2023년 5월 1일

✍ 복습 자료

IP의 한계

비연결성
패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷을 전송한다.
비신뢰성
중간에 패킷이 사라질 수 있다.
=> 클라이언트가 파악할 수 없다.

패킷의 순서를 보장할 수 없다.
=> 전달 데이터의 용량이 클 경우 패킷 단위로 나눠 데이터를 전달하기 때문에 클라이언트가 의도하지 않은 순서로 서버에 패킷이 도착할 수 있다.

OSI 7 계층과 TCP/IP 4 계층

TCP/IP 4 계층은 OSI 7 계층보다 먼저 개발되었으며 TCP/IP 프로토콜의 계층은 OSI 모델의 계층과 정확하게 일치하지는 않는다. 실제 네트워크 표준은 업계표준을 따르는 TCP/IP 4 계층에 가깝다.

TCP

전송 제어 프로토콜 Transmission Control Protocol
1. 연결 지향 - TCP 3 way handshake (가상 연결)
  클라이언트가 서버에게 ACK을 보내면 이 이후로부터 연결이 성립되며 데이터를 전송할 수 있다.
  만약 서버가 꺼져있다면 클라이언트가 SYN을 보내고 서버에서 응답이 없기 때문에 데이터를 보내지 않는다.
  현재에는 최적화가 이루어져 3번 ACK을 보낼때 데이터를 함께 보내기도 한다.
2. 데이터 전달 보증
  데이터 전송이 성공적으로 이루어진다면 이에 대한 응답을 돌려주기 때문에 IP 패킷의 한계인 비연결성을 보완할 수 있다.
3. 순서 보장 (= 신뢰할 수 있는 프로토콜)
  만약 패킷이 순서대로 도착하지 않는다면 TCP 세그먼트에 있는 정보를 토대로 다시 패킷 전송을 요청할 수 있다.
UDP

사용자 데이터그램 프로토콜 User Datagram Protocol
1. 비연결지향
2. 데이터 전달 보증 X
3. 순서 보장 X
4. 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠르다
5. 신뢰성보다는 연속성이 중요한 서비스에 자주 사용된다 (실시간 스트리밍)
TCP vs UDP

HTTP
1. 클라이언트 서버 구조
2. 무상태 프로토콜 (Stateless)
  서버가 클라이언트의 상태를 보존하지 않는다.
  장점 : 서버 확장성 높다 (스케일 아웃)
  단점 : 클라이언트가 추가 데이터를 전송한다.
3. 비연결성 (Connectionless)
  연결을 유지하지 않는 모델이다.
  초 단위 이하의 빠른 속도로 응답한다.
  
  한 시간 동안 수천 명이 서비스를 사용해도, 실제 서버에서는 초당 처리 요청 개수는 수십 개에 이하로 매우작다.
  트래픽이 많고, 큰 규모의 서비스를 운영할 때에는 비연결성은 한계를 보인다.
4. HTTP 메세지
5. 단순함, 확장 가능

Stateful vs Stateless

Stateful
중간에 다른 점원으로 바뀌면 안 된다. => 중간에 다른 점원으로 바뀔 때 상태 정보를 다른 점원에게 미리 알려줘야 한다.

항상 같은 서버가 유지되어야 한다.
서버에 장애가 생긴다면?
상태 정보가 다 날아가 버리므로 처음부터 다시 서버에 요청해야 한다.
Stateless
중간에 다른 점원으로 바뀌어도 된다.
갑자기 고객이 증가해도 점원을 대거 투입할 수 있다. (= 갑자기 클라이언트 요청이 증가해도 서버를 대거 투입할 수 있다.)
응답 서버를 쉽게 바꿀 수 있다. (= 무한한 서버 증설 가능하다.)

아무 서버나 호출해도 된다.
서버에 장애가 생긴다면?
다른 서버에서 응답을 전달하면 되기 때문에 클라이언트는 다시 요청할 필요가 없다.

Stateless의 한계

로그인이 필요 없는 단순한 서비스 소개 화면 같은 경우엔 무상태로 설계할 수 있지만

로그인이 필요한 서비스라면 유저의 상태를 유지해야 되기 때문에 브라우저 쿠키, 서버 세션, 토큰 등을 이용해 상태를 유지한다.
비연결성의 한계와 극복

TCP/IP 연결을 새로 맺어야 한다 => 3 way handshake 시간 추가
웹 브라우저로 사이트를 요청하면 HTML, Javascript, CSS, 추가 이미지 등 수 많은 자원이 함께 다운로드.
현재는 HTTP 지속 연결로 문제를 해결함.
HTTP/2, HTTP/3에서 더 많은 최적화가 이루어짐.

HTTPS

HTTP Secure
기존의 HTTP 프로토콜을 더 안전하게(Secure) 사용할 수 있음을 의미한다.
요청 및 응답 데이터를 암호화한다.
암호화 방식

암호화할 때 사용할 키, 암호화한 것을 해석(복호화)할 때 사용할 키가 필요하다.
암호화와 복호화할 때 사용하는 키가 동일하다면 대칭 키 암호화 방식,
다르다면 공개 키 (비대칭 키) 암호화 방식이라고 한다.
1. 대칭 키 암호화 방식
  두 개의 키를 사용해야 하는 공개 키 방식에 비해서 연산 속도가 빠르다.
  키를 주고받는 과정에서 탈취당했을 경우에는 암호화가 소용없어지기 때문에 키를 관리하는데 신경을 많이 써야 한다.
2. 공개 키 (비대칭 키) 암호화 방식
  두 개의 키를 사용한다. (공개 키, 비밀 키)
  공개 키는 이름 그대로 공개되어 있기 때문에 누구든지 접근 가능하다. 누구든 이 공개 키를 사용해서 암호화한 데이터를 보내면, 비밀 키를 가진 사람만 그 내용을 복호화할 수 있다.
  
  보통 요청을 보내는 사용자가 공개 키를, 요청을 받는 서버가 비밀 키를 가진다. 이때, 비밀 키는 서버가 해킹당하는 게 아닌 이상 탈취되지 않는다.
  
  대칭 키 방식보다 보안성이 더 좋지만 복잡한 연산이 필요하여 더 많은 시간을 소모한다.
SSL / TLS 프로토콜

HTTPS는 HTTP 통신을 하는 소켓 부분에서 SSL 혹은 TLS라는 프로토콜을 사용하여 서버 인증과 데이터 암호화를 진행한다.
1. CA(Certificate Authority)를 통한 인증서 사용
  CA : 인증서를 발급해 주는 공인된 기관
  HTTPS를 사용하면 브라우저가 서버의 응답과 함께 전달된 인증서를 확인할 수 있다. 인증서는 서버의 신원을 보증해준다.
2. 대칭 키, 공개 키 암호화 방식을 모두 사용