[💻 코드스테이츠 FE 44기] [네트워크] 심화 - IP/IP Packet, TCP/UDP, HTTPS

✔️ 시작

네드워크 심화 과정에 대한 이론을 학습했다. 이해할 내용도 많고 단시간에 이해하기엔 시간이 부족했다.

---

📍 네트워크

✔️ 네트워크의 시작

냉전시대에서 핵전쟁을 대비하기 위한 통신망 구축을 위해 추진되었다.이 때 기존에 사용 되었던 회선교환 방식이 아닌 패킷 교환 방식으로 네트워크를 구축하게 되었다.

회선교환 방식?

회선 교환 중간에서 발신자와 수신자를 연결해주는 전화 교화원(오퍼레이터)가 발신자와 수신자 사이에 데이터를 전송할 전용선을 미리 할당하고 둘을 연결

❗️ 단점

• 상대방이 다른 상대와 연결되어 있을 경우 끝날 때 까지 기다려야 한다.
• 회선이 끊어질 경우 처음 부터 다시 연결을 성립해야 한다.

✔️ IP와 IP Packet

• IP(인터넷 프로토콜) 주소를 컴퓨터에 부여해 통신한다.
• IP는 지정한 IP 주소(IP Address)에 패킷(Packet)이라는 통신 단위로 데이터 전달

❗️ 패킷?

• pack + bucket이 합쳐진 단어 (소포로 비유할 수 있다.)
• IP 패킷은 우체국 송장 처럼 전송 데이터를 전송하기 위해 출발지/목적지 IP와 같은 정보가 포함되어 있다.

• 패킷 단위로 전송을 하면 노드들은 목적지 IP에 도달하기 위해 서로 데이터를 전달한다.
• 서버에서 데이터를 전송 받는다면 서버도 이에 대한 응답을 돌려줘야 한다. (IP 패킷을 이용해 응답 전달)

❗️ IP 한계

• 비연결성 (도착한지 안 한지 알 수 없다.)
  - 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
• 비신뢰성
  - 중간에 패킷이 사라질 수 있다.
  - 패킷의 순서를 보장할 수 없다. (데이터 용량이 클 경우 패킷 단위로 나눠 데이터 전달하는데 패킷 들은 중간에 서로 다른 노드를 통해 전달 될 수 있다.)

✔️ TCP (패킷교환 방식 보완)

• 논리적인 접속을 성립하기 위해 3 way handshake(가상 연결)를 사용하는 연결지향형 프로토콜
• 데이터 전달 보증
• 데이터 순서 보장

1. 클라이언트는 서버에 접속 요청하는 SYN 패킷을 보낸다.
2. 서버는 SYN요청을 받고 클라이언트에게 요청을 수락한다.
   • 수락한다는 ACK, SYN가 설정된 패킷을 발송
   • 클라이언트가 다시 ACK으로 응답하기를 기다린다.
3. 클라이언트가 서버에게 ACK을 보내면 이 이후로 부터 연결이 성립 (데이터 전송 가능)

- SYN: Synchronize(요청)
- ACK: Acknowledgment(응답)

• 만약 서버가 꺼져 있다면 클라이언트가 SYN을 보내고 서버에서 응답이 없기 떄문에 데이터 보내지 않음
• 현재는 최적화가 이루어져 3번 ACK을 보낼 때 데이터를 함께 보내기도 한다.
• 데이터 전송이 성공적으로 이루어진다면 이에 대한 응답을 돌려준다. (IP 패킷의 한계인 비연결성 보완)
• 만약 패킷이 순서대로 도착하지 않는다면 TCP 세그먼트에 있는 정보를 토대로 다시 패킷 전송을 요청 (IP 패킷의 한계인 비신뢰성(순서를 보장하지 않음)을 보완)

✔️ UDP (사용자 데이터그램 프로토콜-User Datagram Protocol)

• IP에 PORT, 체크섬 필드 정보만 추가된 단순한 프로토콜
• TCP 보다 신뢰성은 낮지만(순서 보장x, 데이터 전달 보장x) 3 way handshake 방식을 사용하지 않기 때문에 TCP와 비교했을 때 빠른 속도를 보장
• 신뢰성 보단 연속성이 중요한 서비스(ex - 실시간 스트리밍 등)에 자주 사용 된다.

HTTP3는 UDP를 사영해 이미 여러 기능이 구현된 TCP보다는 커스터마이징이 가능하다는 장점이 있다.(기능이 거의 없다.)
(ex - QUIC: 구글이 커스터마이징한 UDP 프로토콜)

✔️ HTTPS(HTTP Secure)

• 기존의 HTTP 프로토콜을 더 안전하게(Secure) 사용할 수 있다.
• 요청과 응답으로 오가는 내용을 암호화 한다.

제3자가 HTTP 요청 및 응답을 탈취한다면 전달되는 데이터의 내용을 그대로 확인할 수 있다.
HTTPS의 경우 데이터가 암호화 되어 요청 및 응답을 중간에 제 3자가 데이터가 탈취 되더라도 그 내용을 알아볼 수 없다.

✔️ 암호화 방식

• 데이터를 암호화 할 때는 암호화할 때 사용할 키, 암호화한 것을 해석(복호화)할 때 사용할 키가 필요하다.
  - 대칭 키 암호화 방식: 암호화와 복호화할 때 사용하는 키가 동일 (하나의 키만 존재)
  • 공개키(비대칭 키) 암호화 방식: 암호화와 복호화할 때 사용하는 키가 다름(두 개의 키가 존재)

1. 대칭 키 암호화 방식

• 하나의 키만 사용한다.
• 암호화할 때 사용한 키로만 복호화가 가능 (암호화할 때 사용한 키와 동일한 키로 복호화 가능)

장점

• 두 개의 키를 사용해야 하는 공개 키 방식에 비해서 연산 속도가 빠르다

단점

• 키를 주고받는 과정에서 탈취당했을 경우 암호화가 소용없어지기에 키를 관리하는데 신경을 많이 써야 한다.

2. 공개 키(비대칭 키) 암호화 방식

• 비대칭 키 암호화 방식은 두 개의 키를 사용

• 암호화할 때 사용한 키와 다른 키로만 복호화가 가능

• 두 개의 키를 각각 공개 키, 비밀 키라고 한다.
  - 공개 키 : 공개되어 있기에 누구든지 접근 가능
  - 비밀 키 : 해당 공개 키를 사용해서 암호화한 데이터는 보내면 비밀 키를 가진 사람만 복호화 할 수 있다.
  (보통 요청을 보내는 사용자가 공개 키, 요청을 받는 서버가 비밀 키를 갖는다.)

장점

• 공개 키를 사용해 암호화한 데이터가 탈취당하더라도 비밀 키가 없다면 복호확 할 수 었다. (보완성이 더 좋다.)

단점

• 대칭 키 방식 보다 더 복잡한 연산이 필요한다. (더 많은 시간 소모)

✔️ SSL/TLS 프로토콜

• HTTPS는 HTTP 통신을 하는 소켓 부분에서 SSL 또는 TLS라는 프로토콜을 사용해 서버 인증과 데이터 암호화를 진행
• SSL이 표준화되며 바뀐 이름이 TLS (둘 다 같은 거)

• CA를 통한 인증서 사용
• 대칭 키, 공개 키 암호화 방식을 모두 사용
  CA(Certificate Authority)

인증서와 CA(Certificate Authority)

• HTTPS를 사용하면 브라우저가 서버의 응답과 함께 전달된 인증서를 확인할 수 있다.(이러한 인증서는 서버의 신원을 보증해준다.)
• 이때 인증서를 발급해 주는 공인된 기관들을 Certificate Authority, CA라고 부른다.

---

✏️ 마치며

단 시간에 배워야하는 내용이 많아서 바로 이해하기 어려웠던 거 같다.
복습을 통해 모르는 부분은 이해하려고 한다.