네트워크

네트워크

---

IP / IP Packet

IP는 IP 주소(IP address)에 패킷이라는 통신 단위로 데이터를 전달합니다.

IP 프로토콜의 대표적인 단점

1. 비연결성
   • 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷을 전송합니다.
2. 비신뢰성
   • 중간에 패킷이 사라질 수 있고, 패킷의 순서를 보장할 수 없습니다.

 

TCP vs UDP

TCP(전송 제어 프로토콜, Transmission Control Protocol)

1. 연결 지향 - TCP 3 way handshake(가상 연결)
2. 데이터 전달 보증
   • 데이터 전송이 성공적으로 이루어진다면 이에 대한 응답을 돌려주기 때문에 IP 패킷의 한계인 비연결성을 보완할 수 있다.
3. 순서 보장
   • 만약 패킷이 순서대로 도착하지 않는다면 TCP 세그먼트에 있는 정보를 토대로 다시 패킷 전송을 요청할 수 있습니다.
4. 신뢰할 수 있는 프로토콜

 

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

1. 비 연결 지향
2. 데이터 전달 보증 X
3. 순서 보장하지 않음
4. 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름
5. 신뢰성보다는 연속성이 중요한 서비스에 자주 사용됨

 

TCP vs UDP

TCP	UDP
연결지향형 프로토콜	비 연결지향형 프로토콜
전송 순서 보장	전송 순서 보장하지 않음
데이터 수신 여부 확인함	데이터 수신 여부 확인하지 않음
신뢰성 높음	신뢰성 낮음
속도 느림	속도 빠름

 

---

 

OSI 7계층 모델과 TCP/IP 4계층 모델

 

 

OSI 7계층 모델

• 1계층 - 물리 계층
  • 시스템 간의 물리적인 연결과 전기 신호를 변환 및 제어하는 계층입니다.
  • 주로 물리적 연결과 관련된 정보를 정의합니다.
  • 주로 전기 신호를 전달하는데 초점을 두고, 들어온 전기 신호를 그래도 잘 전달하는 것이 목표입니다.
• 2계층 - 데이터링크 계층
  • 네트워크 기기 간의 데이터 전송 및 물리주소를 결정하는 계층입니다.
  • 물리 계층에서 들어온 전기 신호를 모아 알아볼 수 있는 데이터 형태로 처리합니다.
  • 이 계층에서는 주소 정보를 정의하고 출발지와 도착지 주소를 확인한 후, 데이터 처리를 수행합니다.
• 3계층 - 네트워크 계층
  • OSI 7 계층에서 가장 복잡한 계층 중 하나로서 실제 네트워크 간에 데이터 라우팅을 담당합니다. 
• 4계층 - 전송 계층
  • 컴퓨터 간 신뢰성 있는 데이터를 서로 주고받을 수 있도록 하는 서비스를 제공하는 계층입니다. 
  • 하위 계층에서 신호와 데이터를 올바른 위치로 보내고 신호를 만드는데 집중했다면, 전송 계층에서는 해당 데이터들이 실제로 정상적으로 보내지는지 확인하는 역할을 합니다. 
  • 네트워크 계층에서 사용되는 패킷은 유실되거나 순서가 바뀌는 경우가 있는 데, 이를 바로 잡아주는 역할도 담당합니다.
• 5계층 - 세션 계층
  • 세션 연결의 설정과 해제, 세션 메시지 전송 등의 기능을 수행하는 계층입니다. 
  • 컴퓨터 간의 통신 방식에 대해 결정하는 계층이라고 할 수 있습니다.
• 6계층 - 표현 계층
  • 응용 계층으로 전달하거나 전달받는 데이터를 인코딩 또는 디코딩하는 계층입니다. 
  • 일종의 번역기 같은 역할을 수행하는 계층이라고 볼 수 있습니다.
• 7계층 - 응용 계층
  • 사용자와의 인터페이스를 제공하는 계층으로 사용자가 실행하는 응용 프로그램들이 해당 계층에 속합니다.

 

데이터의 캡슐화

OSI 7계층 모델은 송신 측의 7계층과 수신 측의 7계층을 통해 데이터를 주고 받습니다. 각 계층은 독립적이므로 데이터가 전달되는 동안에 다른 계층의 영향을 받지 않습니다.

 

 데이터를 전송하는 쪽은 상위 계층에서 하위 계층으로 데이터를 전달하는데, 이때 데이터를 보낼 때 각 계층에서 필요한 정보를 데이터에 추가하는데 이 정보를 헤더(데이터링크 계층에서는 트레일러)라고 합니다. 그리고 이렇게 헤더를 붙여나가는 것을 캡슐화라고 합니다.

 데이터를 받는 쪽은 하위 계층에서 상위 계층으로 각 계층을 통해 전달된 데이터를 받게 됩니다. 이때 상위 계층으로 데이터를 전달하며 각 계층에서 헤더를 제거해 나가는 것은 역캡슐화라고 합니다. 역캡슐화를 거쳐 마지막 응용 계층에 도달하면 원본 데이터만 남게 됩니다.

 

 

TCP/IP 4계층 모델

TCP/IP 4계층 모델은 OSI 모델을 기반으로 실무적으로 이용할 수 있도록 현실에 맞춰 단순화된 모델입니다.

• 1계층 - 네트워크 인터페이스 계층
  • OSI 계층의 물리 계층과 데이터 링크 계층에 해당하며 물리적인 주소로 MAC을 사용합니다.
• 2계층 - 인터넷 계층
  • OSI 계층의 네트워크 계층에 해당하며 통신 노드 간의 IP 패킷을 전송하는 기능 및 라우팅을 담당합니다.
• 3계층 - 전송 계층
  • OSI 계층의 전송 계층에 해당하며 통신 노드 간의 연결을 제어하고, 신뢰성 있는 데이터 전송을 담당합니다
• 4계층 - 애플리케이션 계층
  • OSI 계층의 세션 계층, 표현 계층, 응용 계층에 해당하며 TCP/UDP 기반의 응용 프로그램을 구현할 때 사용합니다.

 

---

 

HTTP

1. 클라이언트 서버 구조
   • 클라이언트와 서버의 Request / Response 구조
2. 무상태 프로토콜(Stateless)
   • 서버가 클라이언트의 상태를 보존하지 않아 서버 확정성이 높지만, 클라이언트가 추가 데이터를 전송하는 단점이 있다.
3. 비연결성(Connectionless)
   • 요청을 주고받을 때만 연결을 유지하고 응답을 주고 나면 TCP/IP 연결을 끊는 시스템으로 최소한의 자원으로 서버 유지를 가능하게 해 효율적입니다.
   • 트래픽이 많고, 큰 규모의 서비스를 운영할 때에는 한계가 있습니다.
4. HTTP 메시지
5. 단순함, 확장 가능

 

HTTP Requests

---

• HTTP Requests는 클라이언트가 서버에서 보내는 메시지입니다.
• Start line
  • 수행할 작업(GET, PUT, POST 등)이나 방식(HEAD or OPTIONS)을 설명하는 HTTP method를 나타냅니다
  • 요청 대상(일반적으로 URL이나 URI) 또는 프로토콜, 포트, 도메인의 절대 경로는 요청 컨텍스트에 작성됩니다
    • origin 형식
      • '?'와 쿼리 문자열이 붙는 절대 경로입니다. GET, POST, HEAD, OPTIONS 등의 method와 함께 사용합니다.
    • absolute 형식
      • 완전한 URL 형식으로, 프록시에 연결하는 경우 대부분 GET method와 함께 사용합니다.
    • authority 형식
      • 도메인 이름과 포트 번호로 이루어진 URL의 일부분 입니다. HTTP 터널을 구축하는 경우, CONNECT와 함께 사용할 수 있습니다.
    • asterisk 형식
      • OPTIONS와 함께 별표(*) 하나로 서버 전체를 표현합니다.
  • HTTP 버전에 따라 HTTP message의 구조가 달라집니다. 따라서 start line에 HTTP 버전을 함께 입력합니다.
• Headers
  • 요청의 Headers는 기본 구조를 따릅니다. 헤더 이름(대소문자 구분이 없는 문자열), 콜론( : ), 값을 입력합니다. 값은 헤더에 따라 다릅니다.
  • Header 종류
    • General headers
      • 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더입니다.
    • Request headers
      • fetch를 통해 가져올 리소스나 클라이언트 자체에 대한 자세한 정보를 포함하는 헤더를 의미합니다.
      • User-Agent, Accept-Type, Accept-Language와 같은 헤더는 요청을 보다 구체화합니다.
      • Referer처럼 컨텍스트를 제공하거나 If-None과 같이 조건에 따라 제약을 추가할 수 있습니다.
    • Representation headers
      • 이전에는 Entity headers로 불렀으며, body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더입니다.
  • 요청에서 사용되는 헤더
    1. Form : 유저 에이전트의 이메일 정보, 검색 엔진에서 주로 사용
    2. Referer : 이전 엡 페이지 주소, 유입경로 수집 가능
    3. User-Agent : 유저 에이전트 애플리케이션 정보, 클라이언트 애플리케이션 정보 등 수집 가능
    4. Host : 요청한 호스트 정보(도메인)
    5. Origin : 서버로 Post 요청을 보낼 때, 요청을 시작한 주소를 나타냄
    6. Authorization : 인증 토큰을 서버로 보낼 때 사용하는 헤더
• Body
  • 요청의 본문은 HTTP messages 구조의 마지막에 위치합니다.
  • POST나 PUT과 같은 일부 요청은 데이터를 업데이트하기 위해 사용합니다.
  • GET, HEAD, DELETE, OPTIONS처럼 서버에 리소스를 요청하는 경우에는 본문이 필요하지 않습니다.
  • Body 종류
    • Single-resource bodies(단일-리소스 본문)
      • 헤더 두 개(Content-Type과 Content-Length)로 정의된 단일 파일로 구성됩니다.
    • Multiple-resource bodies(다중-리소스 본문)
      • 여러 파트로 구성된 본문에서는 각 파트마다 다른 정보를 지닙니다.
      • 보통 HTML form과 관련이 있습니다.

HTTP Responses

---

• HTTP Responses는 서버가 클라이언트에게 보내는 메시지입니다.
• Status line
  • 현재 프로토콜의 버전(HTTP/1.1)
  • 상태 코드 : 요청의 결과를 나타냅니다.
  • 상태 텍스트 : 상태 코드에 대한 설명
• Headers
  • 응답에 들어가는 HTTP headers는 요청 헤더와 동일한 구조를 가지고 있습니다.
  • 대소문자 구분 없는 문자열, 콜론(:), 값을 입력합니다. 값은 헤더에 따라 다릅니다.
  • Header 종류
    • General headers
      • 메시지 전체에 적용되는 헤더로, body를 통해 전송되는 데이터와는 관련이 없는 헤더입니다.
    • Response headers
      • 위치 또는 서버 자체에 대한 정보(이름, 버전 등)와 같이 응답에 대한 부가적인 정보를 갖는 헤더로, Vary, Accept-Ranges와 같이 상태 줄에 넣기에는 공간이 부족했던 추가 정보를 제공합니다.
    • Representation headers
      • 이전에는 Entity headers로 불렀으며, body에 담긴 리소스의 정보(콘텐츠 길이, MIME 타입 등)를 포함하는 헤더입니다.
  • 응답에서 사용되는 헤더
    1. Server : 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보
    2. Date : 메시지가 발생한 날짜와 시간
    3. Loation : 페이지 리디렉션
    4. Allow : 허용 가능한 HTTP 메서드
    5. Retry-After : 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
• Body
  • 응답의 본문은 HTTP messages 구조의 마지막에 위치합니다.
  • 201, 204와 같은 상태 코드를 가지는 응답에는 본문이 필요하지 않습니다.
  • Body 종류
    • Single-resource bodies(단일-리소스 본문)
      • 길이가 알려진 단일-리소스 본문은 두 개의 헤더(Content-Type, Content-Length)로 정의합니다.
      • 길이를 모르는 단일 파일로 구성된 단일-리소스 본문은 Transfer-Encoding이 chunked 로 설정되어 있으며, 파일은 chunk로 나뉘어 인코딩되어 있습니다.
    • Multiple-resource bodies(다중-리소스 본문)
      • 서로 다른 정보를 담고 있는 body입니다.

 

콘텐츠 협상 헤더

클라이언트가 선호하는 표현 요청으로 요청시에만 사용

• Accept : 클라이언트가 선호하는 미디어 타입 전달
• Accept-Charset : 클라이언트가 선호하는 문자 인코딩
• Accept-Encoding : 클라이언트가 선호하는 압축 인코딩
• Accept-Language : 클라이언트가 선호하는 자연 언어

 

---

 

HTTPS

HTTPS는 HTTP Secure 의 약자로, 기존의 HTTP 프로토콜과 달리 요청과 응답으로 오간느 내용을 암호화하기 때문에 더 안전하게 사용할 수 있음을 의미합니다.

 

암호화 방식

데이터를 암호화를 할 때에는 암호화할 때 사용할 키와 암호화한 것을 해석(복호화)할 때 사용할 키가 필요합니다. 이때 암호화와 복호화할 때 사용하는 키가 동일하다면 대칭 키 암호화 방식, 다르다면 공개 키(비대칭 키) 암호화 방식이라고 합니다.

• 대칭키 암호화 방식
  • 하나의 키만 사용하는 방식으로, 암호화할 때 사용한 키와 동일한 키로 복호화가 가능합니다.
  • 연산 속도가 빠르다는 장점이 있지만, 키를 주고받는 과정에서 탈취당했을 경우에는 암호화가 소용없어지기 때문에 키를 관리하는데 신경을 많이 써야 합니다.
• 공개 키(비대칭 키) 암호화 방식
  • 두 개의 키를 사용하는 방식으로, 암호화할 때 사용한 키와 복호화할 때 사용하는 키가 다릅니다.
  • 두 개의 키를 각각 공개 키, 비밀 키라고 부르며 누구든 공개 키를 사용해 암호화한 데이터를 보내면, 비밀 키를 가진 사람만 그 내용을 복호화할 수 있습니다.
  • 공개 키가 탈취당하더라도, 비밀 키가 없다면 복호화할 수 없으므로 대칭 키 방식보다 보안성이 좋습니다.
  • 하지만 대칭 키 방식보다 더 복잡한 연산이 필요하므로 더 많은 시간을 소모합니다.

 

SSL/TLS 프로토콜

HTTPS는 HTTP 통신을 하는 소켓 부분에서 SSL 또는 TLS라는 프로토콜을 사용하여 서버 인증과 데이터 암호화를 진행합니다. 

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

 

인증서와 CA(Certficate Authority)

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

1. 서버는 인증서를 발급받기 위해서 CA로 서버의 정보와 공개 키를 전달합니다
2. CA는 서버의 공개 키와 정보를 CA의 비밀 키로 암호화하여 인증서를 발급합니다.
3. 서버는 클라이언트에게 요청을 받으면 CA에서 발급받은 인증서를 보내줍니다(이때 사용자가 사용하는 브라우저는 CA들의 리스트와 공개 키를 내장하고 있습니다)
4. CA의 비밀 키로 암호화된 데이터(인증서)는 CA의 공개 키로만 복호화가 가능하므로, 정말로 CA에서 발급한 인증서가 맞는지 확인 후 복호화를 진행합니다.
5. 복호화의 성공하면 클라이언트는 서버의 정보와 공개 키를 얻게 됨과 동시에 해당 서버가 신뢰할 수 있는 서버임을 알 수 있게 됩니다.

 

대칭키  전달

사용자가 서버의 인증서를 성공적으로 복호화하여 서버의 공개 키를 확보하면, 이 공개 키는 클라이언트와 서버가 함께 사용하게 될 대칭 키를 주고받을 때 사용하게 됩니다. 대칭 키는 오고 가는 과정에서 탈취될 수 있는 위험성이 있지만, 클라이언트가 서버로 대칭 키를 보낼 때 서버의 공개 키를 사용해서 암호화하여 보내준다면, 서버의 비밀 키를 가지고 있는 게 아닌 이상 해당 대칭 키를 복호화할 수 없으므로 탈취될 위험성이 줄어듭니다.

 

이제 HTTPS 요청을 주고받을 때 이 대칭 키를 사용하여 데이터를 암호화하여 전달하게 됩니다. 요청이 중간에 탈취되어도 제3자가 암호화된 데이터를 복호화할 수 없기 때문에 안전하게 요청과 응답을 주고 받을 수 있습니다.