오늘날의 데이터 통신은 데이터를 패킷 단위로 주고 받는 형식으로 이루어진다. 이 패킷 단위 통신을 기반으로 하는 프로토콜인 IP와 그 위에서 동작하는 프로토콜인 TCP, UDP에 대해 간략하게 알아본다.
송신 호스트(클라이언트)와 수신 호스트(서버)가 패킷 교환 네트워크에서 정보를 주고받는 데 사용하는 정보 위주의 프로토콜로, 호스트의 주소지정과 패킷 분할 및 조립 기능을 담당한다.
데이터를 전송하게 되면 출발지와 목적지 사이의 node(중간 서버)들을 거쳐 최종 목적지(server)에 도착하게 되고, 서버에서도 같은 방법으로 응답을 보낸다.
비 연결성 : 송신측과 수신측이 지속적으로 연결되어 있지 않고, 전송이 한 사이클씩 독립적으로 이루어 진다.
비 신뢰성
두 개의 호스트를 연결하고 데이터를 교환하게 해주는 네트워크 프로토콜로, 데이터와 패킷이 보내진 순서대로 전달하는 것을 보장하며, 네트워크의 정보 전달을 통제한다.
http 요청/응답 메시지가 생성되면, http 메시지는 세션 계층에있는 소켓(socket: 네트워크 환경과의 접점, 인터넷 통신의 종점)
을 통해 전송 계층에 있는 TCP로 전달된다.
TCP는 이전 계층에서 전달된 데이터를 받아 청크 단위로 나누고, TCP 헤더를 붙여 TCP 세그먼트
를 생성하고,
네트워크 계층의 IP는 TCP 세그먼트를 패킷화 해 IP 패킷
을 생성한다.
TCP 세그먼트 : 송∙수신 port, 전송 제어, 순서 검증 등을 포함한다.
연결지향 : 3 way handshake를 통해 송∙수신측의 논리적인 접속을 성립한다.
3번까지 완료되면 연결이 성립된다.
데이터 전달 보증 : 데이터 전송이 성공하면 응답을 돌려준다.
순서 보장: 송신된 패킷의 순서와 수신된 패킷의 순서가 다르면, TCP 세그먼트를 토대로 패킷 전송을 가시 요청할 수 있다
기존 IP에 PORT, 체크섬 필드 정보만 추가된 단순한 프로토콜로, TCP에 비해 신뢰성은 낮지만 3 way handshake 방식을 통한 연결 유지, 전송 순서 보장, 데이터 수신 여부를 지원하지 않기 때문에 TCP와 비교해 빠른 속도를 보장한다.
ISO에서 1984년에 제정한 표준 규격으로, 컴퓨터 네트워크 프로토콜 디자인과 통신을 하드웨어/소프트웨어의 기능에 따라 7개의 계층으로 나누어 설명했다.
1 계층 (물리) : 시스템 간의 물리적인 연결과 전기 신호의 변환/제어를 담당한다.
데이터 단위 : Bit
2 계층 (데이터 링크) : 데이터에 물리주소(MAC) 부여 및 데이터의 물리적인 전송, 에러 검출, 흐름제어를 담당한다.
데이터 단위 : frame
3 계층 (네트워크) : 네트워크 간에 최적의 경로를 탐색하는 라우팅과 ip 주소 부여를 담당한다.
데이터 단위 : packet
4 계층 (전송) : 송∙수신자간 신뢰성 있는 데이터를 주고받을 수 있게 해주며, 데이터들이 정상적으로 보내지는지 확인하는 역할을 담당한다.
데이터 단위 : segment(TCP), datagram(UDP)
5 계층 (세션) : 세션 연결의 설정∙해제, 세션 메시지 전송 등 통신을 하기 위한 세션을 확립/유지/중단해 컴퓨터간 통신방식에 대해 결정한다.
데이터 단위 : message
6 계층 (표현) : 응용 계층으로 전달하거나 전달받는 데이터의 인코딩/디코딩을 담당한다.
데이터 단위 : message
7 계층 (응용) : 최종적으로 사용자와의 인터페이스를 제공하며, 사용자가 사용하는 응용프로그램들이 이에 해당한다.
데이터 단위 : message
OSI 7계층 모델은 송∙수신 측의 7계층을 통해 데이터를 주고 받는다.
각 계층은 독립적이며, 데이터가 전달되는 동안에 다른 계층의 영향을 받지 않는다.
송신
데이터를 보내기 위해서 상위 계층에서 하위 계층으로 데이터를 전달
각 계층에서 필요한 정보를 데이터에 추가(추가된 정보=헤더(데이터링크 계층에서는 트레일러)) - 캡슐화
물리 계층에 도달 : 송신 측의 데이터링크 계층에서 만들어진 데이터가 전기 신호로 변환되어 수신 측에 전송
수신
하위 계층에서 상위 계층으로 데이터 전달
각 계층에서 헤더(또는 트레일러)를 제거 - 역캡슐화
응용 계층에 도달 : 전달을 시작한 원본 데이터 확보
OSI 모델을 기반으로 실무적으로 이용할 수 있도록 단순화된 모델
1계층 (네트워크 인터페이스) : OSI 계층의 물리 계층과 데이터 링크 계층에 해당. 물리적인 주소로 MAC을 사용한다.
2계층 (인터넷 계층) : OSI 계층의 네트워크 계층에 해당. 통신 노드 간의 패킷 전송 및 라우팅을 담당한다.
3계층 (전송) : OSI 계층의 전송 계층에 해당. 통신 노드간의 연결을 제어하고, 신뢰성 있는 데이터 전송을 담당한다.
4계층 (응용) : OSI 계층의 세션 계층에 해당. 표현 계층, 응용 계층에 해당, TCP/UDP 기반의 응용 프로그램을 구현할 때 사용한다.
HTTP는 하이퍼미디어 문서를 전송하기 위한 애플리케이션 레이어 프로토콜을 의미한다.
버전 | 특징 | 기반 프로토콜 | persistent connection | 연도 |
---|---|---|---|---|
0.9 | GET 메서드만 지원 헤더 X | X | 1991 | |
1.0 | 메서드, 헤더 추가 | X | 1996 | |
1.1 | 현재 많이 사용되는 버전중 하나 | TCP | O | 1997 |
2 | 현재 많이 사용되는 버전중 하나 성능 개선 | TCP | O | 2015 |
3 | 성능 개선 | UDP 기반의 QUIC | O | 현재 |
상태를 저장하지 않고, 연결을 유지하지 않기 때문에 기존요청과 관계없는 다른 중개 서버로 요청∙응답을 받아도 문제가 없다.
때문에 서버의 증설이 쉽다는 장점도 가진다.
하지만 규모가 커질수록 서버로부터 데이터를 받아올 때마다 연결∙종료를 실행해 전체적인 속도가 느려진다는 단점을 가졌다.(1.1 이후 버전에서는 persistent connection를 통해 연결이 일정시간 유지된다.)
HTTP 메시지구조에 대한 설명은 다른 포스트에 올라가 있다.
HTTP 메시지는 크게 헤더와 바디로 구분되며
HTTP 바디에서는 데이터 메시지 본문(Message body)을 통해서 표현(Representation) 데이터를 전달한다.
표현은 요청이나 응답에서 전달할 실제 데이터를 뜻하며, 표현 헤더는 표현 데이터를 해석할 수 있는 정보를 제공한다.
요청∙응답 둘다 사용
Content-Type : 표현 데이터 형식
ex) Text/html; charset=utf-8
, application/json
, Image/png
Content-Encoding : 표현 데이터 압축 방식
ex) gzip
, deflate
, identity
Content-Language : 표현 데이터 자연 언어
ex) ko
, en
, en-US
Content-Length : 표현 데이터 길이(byte 단위)
From : 유저 에이전트의 이메일 정보 (검색 엔진에서 주로 사용)
Referer : 이전 웹 페이지 주소 (유입경로 수집 가능)
User-Agent : 유저 에이전트 애플리케이션 정보 (장애가 일어나는 브라우저 파악 가능)
Host : 요청한 호스트 정보(도메인, 필수 헤더)
Origin : 서버로 POST 요청을 보낼 때, 요청을 시작한 주소를 나타냄
Access-Control-Allow-Origin
와 관련
Authorization: 인증 토큰(JWT)을 서버로 보낼 때 사용하는 헤더
“토큰의 종류(e.g. Basic) + 실제 토큰 문자”를 전송
콘텐츠 협상(content negotiation): 표현 헤더 요소에서 Content 대신 Accept로 대채해 사용가능
원하는 언어, 미디어 타입(Accept만 사용) 등
Server : 요청을 처리하는 ORIGIN 서버의 소프트웨어 정보
Date : 메시지가 발생한 날짜와 시간
Location : 페이지 리디렉션
201
(Created) : Location 값은 요청에 의해 생성된 리소스 URI
3xx
(Redirection) : Location 값은 요청을 자동으로 리디렉션하기 위한 대상 리소스를 가리킴
Allow : 허용 가능한 HTTP 메서드
405
(Method Not Allowed)에서 응답에 포함
Retry-After : 유저 에이전트가 다음 요청을 하기까지 기다려야 하는 시간
503
(Service Unavailable) : 서비스가 언제까지 불능인지 고지 가능
기존의 HTTP 프로토콜에 암호와를 통한 보안 시스템을 도입한 프로토콜
응답 요청을 암호화 한다(wireshark를 통해 http 메시지 확인 가능)
데이터 암호화는 암호화할 때 사용하는 키, 암호화한 것을 해석(복호화)할 때 사용하는 키를 이용한다.
대칭 키 암호화 : 암호화키, 복호화키가 동일한 경우
비교적 연산 속도가 빠르지만, 중간에 키를 탈취당하는 상황에 취약해 상대적으로 보안성이 떨어진다.
비대칭 키 암호화 : 암호화키, 복호화키가 동일하지 않은 경우
HTTPS는 HTTP 통신을 하는 소켓에서 SSL 혹은 TLS 프로토콜을 사용해 서버 인증과 데이터 암호화를 진행한다. (SSL이 표준화되며 바뀐 이름이 TLS. 사실상 같은 프로토콜)
CA를 통한 인증서
서버가 인증서를 발급받기 위해서 CA로 서버의 정보와 공개 키를 전달
CA는 서버의 공개 키와 정보를 CA의 비밀 키로 암호화하여 인증서를 발급
서버는 클라이언트에게 요청을 받으면 인증서를 전달
사용자의 브라우저는 해당 인증서가 리스트에 있는 CA가 발급한 인증서인지 확인하고, 리스트에 있는 CA라면 해당하는 공개 키를 통해 인증서를 복호화 (브라우저는 CA들의 리스트와 공개 키를 내장하고 있다)
대칭 키 + 비대칭 키 암호화 방식
사용자가 인증서를 성공적으로 복호화하여 서버의 공개 키를 확보
사용자는 서버 공개키를 통해 데이터를 암호화하여 주고받을 때 사용할 대칭키를 생성
(공개 키 암호화 방식은 보안은 확실하지만, 복잡한 연산이 필요하기 때문에 대칭키를 생성)
대칭 키를 서버의 공개 키로 암호화하여 전달,서버는 전달받은 데이터를 비밀 키로 복호화하여 대칭 키를 확보
HTTPS 요청/응답을 대칭 키를 사용하여 데이터를 암호화하여 전달
Reference
wikipedia-OSI 모형
wikipedia-제어 프로토콜