23.03.06 - TCP/IP, 네트워크 계층 모델, HTTP, HTTPS

1. TCP / IP

1) 회선교환 방식 vs 패킷교환 방식

회선교환 방식

• 통신 회선을 설정하여 데이터를 교환하는 방식
• 연결하려는 회선이 다른 회선과 연결중인 경우 현재 연결된 회선과의 연결이 끝나야만 연결할 수 있음
  (여러개의 회선을 동시에 연결할수 없음)
• 특정 회선이 끊어질 경우 처음부터 다시 연결해야함

 

패킷교환 방식

• 패킷이라는 단위로 데이터를 잘게 나누어 전송하는 방식
• 특정 회선이 전용선으로 할당되지 않음으로 빠르고 효율적으로 데이터 전송이 가능

 

현재의 IP 기반 네트워크는 미 국방성에서 1969년 진행했던 아르파넷(ARPANET) 프로젝트에서 시작됨. 

당시 냉전시대에서 핵전쟁을 대비하기 위해 추진되었고, 이때 패킷교환 방식으로 네트워크를 구축했다.

=> 현재의 인터넷 통신 방식의 기반이 됨

 

 

2) IP Packet

IP는 지정한 IP 주소에 패킷(Packet) 단위로 데이터를 전달함 

IP 패킷에는 출발지 IP, 목적지 IP와 같은 정보가 포함됨

 

단점

• 비연결성
  • 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷을 전송함
    => 데이터가 전달될지 안될지 모름
• 비신뢰성
  • 중간에 패킷이 사라지거나 패킷의 순서를 보장할 수 없음
    => 데이터 도착시 제대로 전달 되었을지 아닐지 모름

 

3) TCP / UDP

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

TCP 프로토콜로 IP 프로토콜의 한계를 보완할 수 있음

• 연결지향 - TCP 3 way handshake(가상연결)
  
  • 클라이언트가 서버에 접속을 요청하는 SYN(Synchronize) 패킷 전송
  • 서버가 SYN 요청을 받고 클라이언트에게 요청을 수락한다는 뜻으로 SYN + ACK(Acknowledgment)가 설정된 패킷 발송
  • 클라이언트가 서버에게 ACK를 보냄
  • 클라이언트와 서버가 연결되고 데이터를 전송할 수 있음
• 데이터 전송시 응답 => 데이터 전달 보증
• 패킷이 순서대로 도착하지 않으면 TCP 세그먼트의 정보로 패킷 재전송 요청 가능
  => 순서가 보장됨. IP의 비신뢰성 보완
• 신뢰할 수 있는 프로토콜

 

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

IP에 PORT, 체크섬(checksum) 필드 정보만 추가된 단순한 프로토콜

*체크섬(checksum) : 중복 검사의 한 형태. 오류 정정을 통해 공간(전자통신) 또는 시간(기억장치) 속에서 송신된 자료의 무결성을 보호하는 단순한 방법

• 흰 도화지에 비유(기능이 거의 없음). 커스터마이징 가능
• 비연결 지향
• 데이터 전달 보증 X
• 순서 보장 X
• 단순하고 빠름
• 신뢰성보다는 연속성이 중요한 서비스(e.g. 실시간 스트리밍)에 자주 사용

최근에는 용량이 큰 데이터를 주고 받을 일이 많고, 속도가 느리면 버퍼링이 발생할 수 있으므로 상황에 따라 UDP를 사용하기도 한다.

 

 

TCP vs UDP

TCP	UDP
연결지향형 프로토콜	비연결지향형 프로토콜
전송 순서 보장 O	전송 순서 보장 X
데이터 수신 여부 확인 O	데이터 수신 여부 확인 X
신뢰성 ↑ 속도 ↓	신뢰성 ↓ 속도 ↑

 

 

 

 

 

 

2. 네트워크 계층 모델

1) OSI 7계층 모델

ISO(International Organization for Standardization)에서 1984년 제정한 표준 규격.

당시에는 같은 회사에서 만든 컴퓨터끼리만 통신이 가능했었기때문에 다른 회사의 시스템이라도 네트워크 유형에 관계 없이 상호 통신이 가능한 규약, 즉 프로토콜이 필요했고 ISO에서 네트워크 표준 규격을 정의함.

 

OSI 7계층 모델의 목적

• 포트, 프로토콜의 호환문제를 해결
• 네트워크 시스템에서 일어나는 일을 해당되는 계층 모델을 통해 쉽게 설명 가능
• 문제 발생시 원인 발생 범위를 좁혀 문제를 쉽게 파악 가능

 

https://www.networkworld.com/article/3239677/the-osi-model-explained-and-how-to-easily-remember-its-7-layers.html

 

• 1. 물리 계층
  • 시스템간의 물리적인 연결과 전기 신호 변환 및 제어하는 계층
  • 물리적 연결과 관련된 정보 정의
  • 전기 신호 전달에 초점을 두고 들어온 신호를 그대로 잘 전달하는 것이 목적
    
    • e.g. 디지털/아날로그로 신호 변경하기. 
• 2. 데이터링크 계층
  • 네트워크 기기간의 데이터 전송 및 물리주소를 결정하는 계층
  • 물리 계층에서 들어온 전기 신호를 알아볼수 있는 데이터 형태로 처리
  • 주소 정보 정의 및 출발지와 도착지 확인 후 데이터 처리
    • e.g. 브리지 및 스위치, MAC 주소
• 3. 네트워크 계층
  • 실제 네트워크간의 데이터 라우팅 담당
  • 라우팅 : 네트어크 내에서 통신데이터를 알고리즘에 의해 최대한 빠르게 보낼 최적의 경로를 선택하는 과정
    • e.g. IP 패킷 전송
• 4. 전송 계층
  • 컴퓨터간 신뢰성 있는 데이터를 서로 주고받도록 서비스 제공
  • 하위 계층에서 보내는 데이터들이 실제로 정상적으로 보내지는지 확인
    • e.g. TCP/UDP 연결
• 5. 세션 계층
  • 세션 연결의 설정/해제, 세션 메시지 전송 등을 수행
  • 컴퓨터간의 통신 방식을 결정
• 6. 표현 계층
  • 응용 계층으로 전달하거나 전달받는 데이터를 인코딩/디코딩 하는 계층
    • e.g. 문자 코드, 압축, 암호화 등의 데이터 변환
• 7. 응용 계층
  • 최종적으로 사용자와의 인터페이스를 제공하는 계층
  • 사용자가 실행하는 응용 프로그램들이 속함
    • e.g. Chrome, 이메일 및 파일 전송, 웹 사이트 조회

 

(1) 데이터 캡슐화

캡슐화

데이터 송신시 상위 계층에서 하위 계층으로 데이터를 전달하면서 헤더(각 계층에서 필요한 정보. 데이터링크 계층에서는 트레일러)를 추가하는것

 

역캡슐화

데이터 수신시 하위 계층에서 상위 계층으로 데이터를 전달하면서 헤더를 제거하는 것

 

송신 => 캡슐화 => 역캡슐화 => 수신 과정을 거치면 전달하고자 하는 원본 데이터만 남음

 

 

 

2) TCP / IP 4계층 모델

OSI 모델을 기반으로 실무적으로 이용할 수 있게 현실에 맞춰 단순화된 모델. 

 

• 4. 어플리케이션 계층
  • OSI 계층의 세션, 표현, 응용 계층에 해당. TCP/UDP 기반의 응용 프로그램 구현시 사용
    • e.g. FTP, HTTP, SSH
• 3. 전송 계층
  • OSI 계층의 전송 계층에 해당. 통신 노드간의 연결 제어, 신뢰성 있는 데이터 전송 담당
    • e.g. TCP/UDP
• 2. 인터넷 계층
  • OSI 계층의 네트워크 계층에 해당. 통신 노드간의 IP 패킷 전송하는 기능 및 라우팅 담당
    • e.g. IP, ARP, RARP
• 1. 네트워크 인터페이스 계층
  • OSI 계층의 물리, 데이터링크 계층에 해당. 물리적인 주소로 MAC을 사용
    • e.g. LAN, 패킷 망 등에 사용

 

 

 

 

 

3. HTTP

HTTP/1.1, HTTP/2 = TCP 기반

HTTP/3 = UDP 기반

 

1) 클라이언트 - 서버 구조

 

• 요청(Request)-응답(Response) 구조
• 클라이언트 - 서버에 요청 보내고 응답 대기
• 서버 - 요청에 대한 결과를 만들어 응답

 

 

2) 무상태성(Stateless)

• 서버가 클라이언트의 상태를 보존하지 않음. 서버는 상태가 없고 클라이언트가 상태를 갖게 함
• 서버는 증설이 쉬워지고 확장성이 높아짐(스케일 아웃 - 수평 확장에 유리함)
• 하지만 클라이언트가 추가 데이터를 전송해야하기 때문에 요청의 용량이 커지는 단점이 있음
• 무상태로 설계할 수 없는 경우가 있음 
  • e.g. 로그인 - 로그인 한 사용자의 경우 로그인 했다는 상태를 서버에 유지시켜야함
  • => 상태 유지는 최소한만 사용하도록 한다

 

3) 비연결성(Connectionless)

• 실제로 요청을 주고받을 때만 연결을 유지하고 응답을 받은 뒤에는 TCP/IP 연결을 끊음
• HTTP 1.0 기준, HTTP는 연결을 유지하지 않는 모델임
• 트래픽이 많고 큰 규모의 서비스 운영시 한계 발생
  • TCP/IP 연결을 새로 맺어야함 => 3 way handshake 시간 추가
  • 사이트 요청시 HTML, JS, CSS, 추가 이미지 등 많은 자원이 함께 다운로드 되어야함
    => HTTP 지속 연결(Persistent Connections)로 해결

 

• • HTTP 1.1에서 지속 연결로 해결했지만 여전히 동기적으로 작동하기 때문에 발생하는 비효율이 있음
  • 파이프라인으로 동시에 요청(비동기) => 하지만 응답이 동기적으로 오기때문에 비효율 발생
  • HTTP 2에서 멀티 플렉싱으로 해결. 요청과 응답 모두 비동기적으로 보내고 받기 가능.

 

 

 

 

 

4) HTTP Headers

(1) 표현 헤더(Representation Headers)

표현 : 요청/응답에서 전달할 실제 데이터.

표현 헤더 : 표현 데이터를 해석할 수 있는 정보 제공. ex) 데이터 유형(html, json), 데이터 길이, 압축 정보 등

 

HTTP 전송에 필요한 부가정보를 담기 위해 사용한다. 필요시 임의의 헤더를 추가할 수도 있다. 

요청, 응답 모두 사용한다.

 

형식

<field-name> : <field-value>
// field-name은 대소문자 구분 없음

 

• Content-Type : 표현 데이터의 형식 설명
  • 미디어 타입이나 문자 인코딩 등
• Content-Encoding : 표현 데이터의 압축 방식
  • 표현 데이터 압축을 위해 사용
  • 데이터 전달하는 쪽에서 압축 후 인코딩 헤더 추가
  • 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축 해제
• Content-Language : 표현 데이터의 자연 언어
• Content-Length : 표현 데이터의 길이
  • 바이트 단위
  • Transfer-Encoding(전송 코딩) 사용시에는 사용하면 안됨. Transfer-Encoding은 chunked의 방식으로 사용

 

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

From: 유저 에이전트의 이메일 정보

• 일반적으로 잘 사용하지 않음
• 검색 엔진에서 주로 사용
• 요청에서 사용

 

Referer: 이전 웹 페이지 주소

• 현재 요청된 페이지의 이전 웹 페이지 주소
• A → B로 이동하는 경우 B를 요청할 때 Referer: A를 포함해서 요청
• Referer를 사용하면 유입경로 수집 가능
• 요청에서 사용
• referer는 단어 referrer의 오탈자이지만 스펙으로 굳어짐

 

User-Agent: 유저 에이전트 애플리케이션 정보

• 클라이언트의 애플리케이션 정보(웹 브라우저 정보, 등등)
• 통계 정보
• 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
• 요청에서 사용
• e.g.
  • user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/ 537.36 (KHTML, like Gecko) Chrome/86.0.4240.183 Safari/537.36

 

Host: 요청한 호스트 정보(도메인)

• 요청에서 사용
• 필수 헤더
• 하나의 서버가 여러 도메인을 처리해야 할 때 호스트 정보를 명시하기 위해 사용
• 하나의 IP 주소에 여러 도메인이 적용되어 있을 때 호스트 정보를 명시하기 위해 사용

 

Origin: 서버로 POST 요청을 보낼 때, 요청을 시작한 주소를 나타냄

• 여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 에러가 발생한다.
• 응답 헤더의 Access-Control-Allow-Origin와 관련

 

Authorization: 인증 토큰(e.g. JWT)을 서버로 보낼 때 사용하는 헤더

• “토큰의 종류(e.g. Basic) + 실제 토큰 문자”를 전송
• e.g.
  • Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l

 

 

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

Server: 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보

• 응답에서 사용
• e.g.
  • Server: Apache/2.2.22 (Debian)
  • Server: nginx

 

Date: 메시지가 발생한 날짜와 시간

• 응답에서 사용
• e.g.
  • Date: Tue, 15 Nov 1994 08:12:31 GMT

 

Location: 페이지 리디렉션

• 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 리다이렉트(자동 이동)
• 201(Created): Location 값은 요청에 의해 생성된 리소스 URI
• 3xx(Redirection): Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를 가리킴

 

Allow: 허용 가능한 HTTP 메서드

• 405(Method Not Allowed)에서 응답에 포함
• e.g.
  • Allow: GET, HEAD, PUT

 

Retry-After: 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간

• 503(Service Unavailable): 서비스가 언제까지 불능인지 알려줄 수 있음
• e.g.
  • Retry-After: Fri, 31 Dec 2020 23:59:59 GMT(날짜 표기)
  • Retry-After: 120(초 단위 표기)

 

 

(2) 콘텐츠 협상(Content negotiation) 헤더

클라이언트가 선호하는 표현을 요청하는 헤더이다.

협상 헤더는 요청시에만 사용한다.

 

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

Quality Values(q)

협상 헤더에서는 원하는 콘텐츠에 대한 우선순위를 지정할 수 있다.

• 0~1. 클수록 높은 우선순위를 가진다. 생략하는 경우는 1.
• ex) Accept-Language : ko-KR, ko;q=0.9, en-US;q=0.8,en;q=0.7
  • 1순위로 한국어 요청
  • 2순위로 영어 요청

 

 

 

 

4. HTTPS

HTTP Secure. HTTP 프로토콜을 더 안전하게 사용할 수 있음. => 요청과 응답으로 오가는 내용을 암호화

 

1) 암호화 방식

(1) 대칭키 

하나의 키만 사용. 암호화 할때 사용한 키로만 복호화가 가능.

연산 속도가 빠르지만 키를 주고 받는 과정에서 탈취당했을 경우 암호화가 소용이 없기 때문에 키를 관리하는데 신경을 많이 써야한다. 

 

(2) 공개키(비대칭키)

공개키, 비밀키 두개의 키를 사용. 암호화 할때 사용한 키와 다른 키로만 복호화가 가능. 

사용자가 공개키를, 서버가 비밀키를 가짐. 비밀키는 서버가 해킹당하는게 아닌 이상 탈취되지 않는다.

공개키를 사용해 암호화한 데이터가 탈취당하더라도 비밀키가 없다면 복호화 할 수 없음

=> 대칭키보다 보안성이 좋음. 하지만 대칭키보다 복잡한 연산이 필요하기때문에 더 많은 시간을 소모함 

 

 

2) SSL/TLS 프로토콜

SSL이 표준화 되며 바뀐 이름이 TLS이다. 

CA(Certificate Authority; 인증서를 발급해주는 공인된 기관들)를 통한 인증서를 사용하고 대칭키, 공개키 암호화 방식을 모두 사용하는것이 특징.

HTTPS는 HTTP 통신을 하는 소켓 부분에서 SSL/TLS 프로토콜을 사용해 서버 인증과 데이터 암호화를 진행함.

 

1. 서버가 자기 공개키를 CA에 보냄
2. CA는 서버의 정보와 공개키를 확인 한 후 자기의 비공개 키를 사용해 받은 내용을 암호화하고, 이것이 인증서가 된다. 
3. 서버가 인증서를 발급받고 클라이언트에게 보낸다.
4. 클라이언트는 브라우저로 인증서를 확인한다. 브라우저는 믿을만한 CA들의 공개키를 내장하고 있다.
5. 신뢰하는 인증기관의 인증서라면 가지고 있던 공개키로 인증서를 열어본다.
   1. 인증서가 풀리지 않을 경우 => 신뢰할 수 없는 인증서. 연결이 중단됨
   2. 인증서가 풀릴 경우 => 신뢰할 수 있는 인증서. 
6. 인증서가 풀리면 인증서 안의 서버 공개키와 정보를 클라이언트가 확인한다.
7. 클라이언트는 자신과 서버가 함께 사용할 대칭키를 만들고, 이 대칭키를 서버 공개키로 암호화 한 다음 서버에 보낸다.
8. 서버가 받은 내용을 서버의 비공개키로 열고 클라이언트에서 보낸 대칭키를 받는다.
   => 서버와 클라이언트가 동일한 대칭키를 가지게 된다!
9. 이 대칭키로 데이터를 암호화/복호화 하여 데이터를 주고 받는다.

=> 복호화 하는 시간이 줄어든다. 대칭키 자체가 오고가는 일이 없기 때문에 중간에서 데이터를 가로채기 어려움으로 해킹의 위험이 줄어든다. 

 

결론

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

 

 

 

************************************

참고

 

https://www.networkworld.com/article/3239677/the-osi-model-explained-and-how-to-easily-remember-its-7-layers.html

The OSI model explained and how to easily remember its 7 layers