프로토콜/Protocol

Seongmin·2022년 11월 7일

CS network

CS

목록 보기

2/6

PROTOCOL

컴퓨터 내부에서, 또는 컴퓨터 사이에서 데이터의 교환 방식을 정의하는 규칙 체계

HTTP

HTML 문서와 같은 리소스들을 가져올 수 있도록 해주는 프로토콜

클라이언트-서버 프로토콜 : 수신자(보통 웹 브라우저) 측에 의해 요청이 초기화 되는 프로토콜
하나의 완전한 문서는 텍스트, 레이아웃 설명, 이미지, 비디오, 스크립트 등 불러온(fetched) 하위 문서들로 재구성

request : 클라이언트(브라우저)에 의해 전송되는 메시지
response : 서버에서 응답으로 전송되는 메시지
일반적으로 80번 포트를 사용

HTTP 흐름

TCP 연결을 연다.

HTTP 메시지를 전송한다.

GET / HTTP/1.1    - 헤더
Host: developer.mozilla.org    - 호스트
Accept-Language: fr

서버에 의해 전송된 응답을 읽는다.

HTTP/1.1 200 OK

Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html

<!DOCTYPE html... (here comes the 29769 bytes of the requested web page)

TCP (Transmission Control Protocol)

컴퓨터가 다른 컴퓨터와 데이터 통신을 하기 위한 프로토콜

절차

상대에게 통신을 하고 싶다는 메시지를 보낸다.(SYN)
상대는 그 메시지에 대한 응답 + 나도 통신 준비가 되었다는 메시지를 보낸다.(SYN-ACK)
2번에서 받은 메시지에 응답을 보낸다.(ACK)

TCP/IP

OSI 7

물리 : 데이터를 전기적인 신호로 변환해서 주고받는 기능을 진행하는 공간
데이터 링크 : 물리 계층으로 송수신되는 정보를 관리하여 안전하게 전달되도록 도와주는 역할

Mac 주소를 통해 통신
네트워크 : 데이터를 목적지까지 안전하고 빠르게 전달

라우터를 통해 이동할 경로 선택, IP 주소 지정, 해당 경로에 따라 패킷 전송
전송 : 프로토콜을 통해 통신 활성화

포트를 개방하고 프로그램들이 전송을 할 수 있도록 제공
세션 : 데이터가 통신하기 위한 논리적 연결

TCP/IP 세션을 만들고 없앰
표현 : 데이터 표현에 대한 독립성을 제공하고 암호화
응용 : 최종 목적지로 응용 프로세스와 직접 연계하여 일반적인 응용 서비스를 수행

TCP/IP

네트워크 인터페이스 계층 : 이더넷, Wi-Fi
인터넷 계층 : IP(IPv4, IPv6)
전송 계층 : TCP, UDP …
응용 계층 : DNS, TLS/SSL, FTP, HTTP, SSH …

응답 코드

https://developer.mozilla.org/ko/docs/Web/HTTP/Status

But,

http는 기본적으로 텍스트 교환이고, html 또한 텍스트이다. 신호를 도청당한다면 내용이 노출된다.

HTTPS

TLS를 사용해 암호화된 연결을 하는 HTTP
→ HTTP over TLS

TLS : 인터넷에서의 정보를 암호화해서 송수신하는 프로토콜, 상호 간의 신뢰를 알리기 위해 전자 서명이 포함된 인증서를 사용하여 통신 내용을 암호화하며, 통신 암호화에 공개키 암호화 방식을 이용한다.

💡 TLS + HTTP = HTTPS

TLS(Transport Layer Security)

인터넷에서의 정보를 암호화해서 송수신하는 프로토콜

TCP/IP 네트워크를 사용하는 통신에 적용되며, 통신 과정에서 전송계층
종단간 보안과 데이터 무결성을 확보해준다.

절차

서버와 클라이언트 간 지원 가능한 알고리즘 서로 교환
키 교환, 인증 (공개키 방법 등)
대칭키 암호로 암호화하고 메시지 인증

메시지 인증? → MAC(Message Authentication Code) 알고리즘

암호 과정

암호화, 복호화 시킬 수 있는 서로 다른 키 2개가 존재하는데 이 두 개의 키는 서로 1번 키로 암호화하면 반드시 2번 키로만 복호화 할 수 있고 2번 키로 암호화하면 반드시 1번 키로만 복호화 할 수 있다.

1번 키를 공개키로 만들어 공개키 저장소에 등록하여 모두에게 공개한다.

2번 키는 서버만 알 수 있도록 개인키로써 소유한다.

→ 공개키로 암호화된 http 요청(https 프로토콜)이 온다면, 서버는 개인키를 이용하여 공개키로 암호화된 문장을 해독한다. 서버는 다시 요청에 맞는 응답을 개인키로 암호화하여 클라이언트에게 전송한다.

과정

먼저 애플리케이션 서버(A)를 만드는 기업은 HTTPS를 적용하기 위해서 공개키와 개인키를 만듭니다.
그 다음에 신뢰할 수 있는 CA 기업을 선택하고 그 기업에 내 공개키를 관리해달라고 계약하고 돈을 지불합니다.
계약을 완료한 CA 기업은 또 CA 기업만의 공개키와 개인키가 있습니다.

CA 기업은 CA기업의 이름과 A서버의 공개키, 공개키의 암호화 방법 등의 정보를 담은 인증서를 만들고, 해당 인증서를 CA 기업의 개인키로 암호화해서 A서버에게 제공합니다.

A서버는 암호화된 인증서를 갖게 되었습니다. 이제 A서버는 A서버의 공개키로 암호화된 HTTPS 요청이 아닌 요청(Request)이 오면 이 암호화된 인증서를 클라이언트에게 줍니다.
이제 클라이언트 입장에서, 예를 들어 A서버로 index.html 파일을 달라고 요청했습니다. 그러면 HTTPS 요청이 아니기 때문에 CA기업이 A서버의 정보를 CA 기업의 개인키로 암호화한 인증서를 받게되겠지요.
여기서 중요합니다. 세계적으로 신뢰할 수 있는 CA 기업의 공개키는 브라우저가 이미 알고 있습니다!
브라우저가 CA 기업 리스트를 쭉 탐색하면서 인증서에 적혀있는 CA기업 이름이 같으면 해당 CA기업의 공개키를 이미 알고 있는 브라우저는 해독할 수 있겠죠? 그러면 해독해서 A서버의 공개키를 얻었습니다.
그러면 A서버와 통신할 때는 A서버의 공개키로 암호화해서 Request를 날리게 되겠죠.