[C/F TIL] 55일차 - TCP/ IP/ IP Packet/ TCP/ UDP

Code States
Front-end boost camp
Today
I
Learned

🐾 폭우 내리는 55일차

---

🐾 회선교환 방식?

• 패킷교환 방식 이전의 방식
• 발신자와 수신자를 회선으로 직접 연결
• 비효율적이고 즉시성이 떨어짐
• 이를 보완하기 위해? : 패킷교환 방식 등장!

🐾 IP/ IP Packet

• IP : 인터넷 프로토콜
• 복잡한 인터넷 망 속 수많은 노드(하나의 서버 컴퓨터)들을 지나 클라이언트와 서버가 통신하기 위한 규율
• IP 패킷 : pack과 bucket이 합쳐진 단어, 소포로 비유 가능
• 패킷 단위로 전송 시 노드들은 목적지 IP에 도달하기 위해 서로 데이터 전달 -> 복잡한 인터넷 망 사이에서도 정확한 목적지로 패킷 전송 가능
• 정확한 출발지와 목적지를 파악할 수 있다는 점에서 적절한 통신 방법으로 보이지만 다음과 같은 한계도 존재
  -- 비연결성 : 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
  -- 비신뢰성 : 중간에 패킷이 사라질 수 있음/ 패킷의 순서 보장 불가

🐾 TCP / UDP

• IP Packet의 한계를 보완하기 위해 탄생
• 네트워크 프로토콜 계층 : OSI 7계층 & TCP/IP 4계층
  
  -- IP 프로토콜 보다 더 높은 계층에 TCP 프로토콜이 존재하기 때문에 앞서 다룬 IP 프로토콜의 한계를 보완할 수 있다.
• 소켓(Socket) : 프로그램이 네트워크에서 데이터를 송수신할 수 있도록, "네트워크 환경에 연결할 수 있게 만들어진 연결부"
• TCP 세그먼트에는 IP 패킷의 출발지 IP와 목적지 IP 정보를 보완할 수 있는 출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보 들을 포함
• TCP 특징 :
  -- 연결 지향
  -- 데이터 전달 보증
  -- 순서 보장
  -- 신뢰할 수 있는 프로토콜
• UDP : IP에 PORT, 체크섬 필드 정보만 추가된 단순 프로토콜
• UDP 특징 :
  -- 하얀 도화지에 비유(기능이 거의 없음)
  -- 비 연결지향
  -- 데이터 전달 보증 X
  -- 순서 보장 X
  -- 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름
  -- 신뢰성보다는 연속성이 중요한 서비스에 자주 사용됨
• TCP vs UDP
  

🐾 OSI 7계층 모델

• 과거에는 다른 회사의 시스템이라도 네트워크 유형에 관계 없이 상호 통신이 가능한 규약인 프로토콜이 필요했음
• 이를 보완하기 위해 국제표준화기구에서 1984년에 제정한 표준 규격 탄생
  
• 각 컴퓨터 간 데이터를 전송할 때 컴퓨터 내부에서는 여러 일을 하는데 하드웨어 및 소프트웨어가 수행하는 기능에 따라 이를 7개의 계층으로 구분했음
• 1계층 : 물리계층 -> 2계층: 데이터링크 계층 -> 3계층: 네트워크 계층 -> 4계층: 전송 계층 -> 5계층: 세션 계층 -> 6계층: 표현 계층 -> 7계층: 응용 계층
• OSI 7계층 모델은 송신 측의 7계층과 수신 측의 7계층을 통해 데이터를 주고 받으며 각 계층은 독립적이므로 데이터가 전달되는 동안 다른 계층의 영향 x
• 데이터를 상대방에게 보낼 때 각 계층에서 필요한 정보를 데이터에 추가하는데 이 정보를 헤더(데이터링크 계층에서는 트레일러)라고 함. -> 이를 캡슐화라고 함 (위에서 아래로)
• 반대로 상위 계층으로 데이터를 전달하며 각 계층에서 헤더를 제거해 나가는 것을 역캡슐화라고
  
  -- 역캡슐화를 거쳐 마지막 응용 계층에 도달하면 드디어 전달하려고 했던 원본 데이터만 남음

🐾 TCP/ IP 4계층 모델

• OSI 모델을 기반으로 실무적으로 이용할 수 있도록 현실에 맞춰 단순화된 모델
• OSI 7계층 이론을 실제 사용하는, 즉 실용성에 기반을 둔 현대의 인터넷 표준
• 4계층: 어플리케이션 계층 -> 3계층: 전송 계층 -> 2계층: 인터넷 계층 -> 1계층: 네트워크 인터페이스 계층
• 응용 계층 : 네트워크 모델의 최상위 계층으로 최종적으로 사용자와의 인터페이스를 제공하는 계층
  -- 예시 : 사용자가 웹 서핑을 할 때에는 웹 브라우저를 사용하고 메일을 주고받을 때는 Outlook과 같은 메일 프로그램을 사용함!
• 응용 계층의 클라이언트와 서버 ▼
  

🐾 HTTP의 특징

• 클라이언트 서버 구조
  -- Request Response 구조
  -- 클라이언트는 서버에 요청을 보내고, 응답을 대기
  -- 서버가 요청에 대한 결과를 만들어 응답
• 무상태성 프로토콜(Stateless), 비연결성(Connectionless)
  -- 장점: 서버 확장성 높음/ 단점: 클라이언트가 추가 데이터 전송
  
• HTTP 메세지
• 단순함, 확장 가능

🐾 HTTP 헤더

• HTTP 메세지는 헤더와 바디로 구분
• 바디에서는 데이터 메세지 본문을 통해서 표현 데이터를 전달
  -- 데이터 메세지 본문 : Message body
  -- 표현(Representation) 데이터
  -- 페이로드(Payload) : 데이터를 실어 나름
  
• 헤더 형식 : <'field-name'>:<'field-value'>
  -- field-name은 대소문자 구분 없음
• 헤더 용도 : HTTP 전송에 필요한 모든 부가정보를 담기 위해 사용

✔️ 표현 헤더 : 요청, 응답 둘 다 사용

• Content-Type : 표현 데이터의 형식
• Content-Encoding: 표현 데이터의 압축 방식
• Content-Language: 표현 데이터의 자연 언어
• Content-Length: 표현 데이터의 길이

✔️ 요청(Request)에서 사용되는 헤더

• From : 유저 에이전트의 이메일 정보
• Referer : 이전 웹 페이지 주소
• User-Agent : 유저 에이전트 애플리케이션 정보
• Host : 요청한 호스트 정보(도메인)
• Origin : 서버로 POST 요청을 보낼 때, 요청을 시작한 주소를 나타냄
• Authorization : 인증 토큰을 서버로 보낼 때 사용하는 헤더

✔️ 응답(Response)에서 사용되는 헤더

• Server : 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보
• Date : 메세지가 발생한 날짜와 시간
• Location : 페이지 리디렉션
• Allow : 허용 가능한 HTTP 메서드
• Retry-After : 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

✔️ 콘텐츠 협상 (Content negotiation)

• Accept : 클라이언트가 선호하는 미디어 타입 전달
• Accept-Charset : 클라이언트가 선호하는 문자 인코딩
• Accept-Encoding : 클라이언트가 선호하는 압축 인코딩
• Accept-Language : 클라이언트가 선호하는 자연 언어
• 협상 헤더는 요청시에만 사용

🐾 HTTPS

• HTTP Secure : HTTP 프로토콜을 더 안전하게 사용할 수 있음을 의미

✔️ 암호화 방식

• 대칭 키 암호화 방식 : 하나의 키만 존재
  -- 암호화할 때 사용한 키로만 복호화 가능
  -- 연산 속도가 빠름
  -- 키를 주고받는 과정에서 탈취당했을 경우 암호화가 소용 없어져 키를 관리하는데 신경을 많이 써야함
  

• 공개 키(비대칭 키) 암호화 방식 : 두 개의 키가 존재
  -- 암호화할 때 사용한 키와 다른 키로만 복호화 가능

• 공개 키 : 누구든지 접근 가능

• 비밀 키 : 비밀 키를 가진 사람만 그 내용을 복호화 가능

• 요청을 받는 서버가 비밀 키를 가지는데, 서버가 해킹당하는게 아닌 이상 탈취되지 않음

• 보안성이 더 좋다

• 더 복잡한 연산이 필요해 더 많은 시간을 소모해야함
  

✔️ SSL / TLS 프로토콜

• SSL이 표준화되면서 바뀐 이름이 TLS이므로 사실상 같은 프로토콜
  -- CA를 통한 인증서 사용
  -- 대칭 키, 공개 키 암호화 방식을 모두 사용
• 인증서와 CA : HTTPS를 사용하면 브라우저가 서버의 응답과 함께 전달된 인증서를 확인
  -- 이러한 인증서는 서버의 신원을 보증해 주며, 이때 인증서를 발급해 주는 공인된 기관들을 Certificate Authority, CA 라고 부름
• 서버는 클라이언트에게 요청을 받으면 CA에게 발급받은 인증서를 보내줌, 이때 사용자가 사용하는 브라우저는 CA들의 리스트와 공개 키를 내장하고 있음
• CA의 비밀 키로 암호화된 데이터(인증서)는 CA의 공개 키로만 복호화가 가능하므로, 정말로 CA에서 발급한 인증서가 맞다면 복호화가 성공적으로 진행되어야 함
• 성공된다면? 클라이언트는 서버의 정보와 공개 키를 얻게 됨과 동시에 해당 서버가 신뢰할 수 있는 서버임을 알 수 있게 됨
• 실패한다면? 이는 서버가 보내준 인증서가 신뢰할 수 없는 인증서임을 확인하게 됨

---

• 대칭 키 전달 : 공개 키는 클라이언트가 서버와 함께 사용하게 될 대칭 키를 주고받을 때 씀
• 속도는 빠르지만 오고가는 과정에서 탈취될 수 있는 위험을 방지하고자 서버의 공개 키를 사용해 암호화해서 보냄

---

• SSL / TLS? 서버와 클라이언트 간의 CA를 통해 서버를 인증하는 과정과 데이터를 암호화하는 과정을 아우른 프로토콜을 SSL 또는 TLS라고 함
  -- HTTPS? HTTP에 SSL/ TLS 프로토콜을 더한 것