TIL: 2022-11-09

⚙️ 오늘 배운 주제

네트워크 심화

 

🐹 오늘의 기분

오늘은 하루종일 솔로로 진행했다. 역시 집중을 위해 열품타를 켜놓고 했다. 내용이 많아보여서 주어진 시간 안에 다 할 수 있을까 걱정이었는데 딴 생각 안 하고 집중해서 하니까 시간이 약간 남았다. 이론 학습을 끝내고 mkcert로 인증서를 받아서 https 서버를 만들어보는 실습도 했는데 신기했다. 서버 파트에서 배웠던 내용을 고새 다 까먹어버려서 잠시 현타 왔었음.... 

대칭 키, 공개 키 암호화 방식까지는 그럭저럭 이해했는데 HTTPS 암호화 방식이랑 CA가 나오면서부터 점점 뇌가 멈추기 시작했다. 아직 잘 모르겠어서 영상이나 블로그 글들을 더 찾아보려고 한다. 

 

🗝 키워드

OSI 7 layers, TCP/IP 4 layers, TCP, UDP, 패킷, 암호화와 복호화, HTTPS, 표현헤더, 협상헤더, CA

 

🗣 복습

네트워크의 변화

회선교환 방식

알파넷
전화교환원이 존재.
전화교환원이 전용선을 미리 할당하고 둘을 연결해주는 방식
-> 회선이 사용 중이더라도 쓸 수 있는 방법을 고안하게 됨. 패킷교환 방식의 등장

패킷교환 방식

특정 회선이 전용선으로 할당되지 않기 때문에 빠르고 효율적인 데이터 전송 가능
소포를 보내듯 데이터를 전송한다.
패킷 = 통신 단위

IP/IP Packet

IP = 인터넷 프로토콜
IP 패킷에는 데이터를 무사히 전송하기 위한 출발지 IP, 목적지 IP 같은 정보가 담겨 있음.
서버가 보내는 응답도 패킷 형태로 전송된다.

한계

비연결성: 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷을 전송한다.
비신뢰성: 중간에 패킷이 사라질 수 있다. 패킷의 순서를 보장할 수 없다. (의도하지 않은 순서로 패킷이 도착할 수 있음)

TCP vs UDP

OSI 7 레이어와 TCP/IP 프로토콜 중 실제 업계 표준은 TCP/IP 프로토콜에 가깝다.

TCP 패킷

출발지 PORT, 목적지 PORT, 전송 제어, 순서, 검증 정보 등을 포함.

특징

• 연결 지향 - TCP 3 way handshake
• 데이터 전달 보증
• 순서 보장
• 신뢰할 수 있는 프로토콜

SYN 패킷 -> SYN + ACK 발송 -> ACK -> 연결 성립
서버에서 응답이 없으면 데이터를 보내지 않음.

데이터 전송이 성공적으로 이루어진다면 응답을 돌려주기 때문에 비연결성을 보완할 수 있다.
순서대로 도착하지 않는다면 세그먼트에 있는 정보를 토대로 다시 요청할 수 있음. (비신뢰성 보완)

UDP 패킷

특징

• 기능이 거의 없음
• 비연결지향
• 데이터 전달 보증 X
• 순서 보장 X
• 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠르다.
• 신뢰성보다는 연속성이 중요한 서비스에 자주 사용된다 (스트리밍)

네트워크 통신

계층별로 나눈 이유
데이터 캡슐화

OSI 7 layers

계층을 나누고 각 계층의 표준을 정함.
표준화를 통해 포트, 프로토콜의 호환 문제를 해결하기 위함.
+ 네트워크 시스템에서 일어나는 일을 쉽게 설명할 수 있게 됨.
+ 문제 발생 시 범위를 좁혀 생각할 수 있다.

 

송신 측의 7계층과 수신 측의 7계층을 통해 데이터를 주고받음.
각 계층은 독립적임. 다른 계층의 영향을 받지 않는다.

캡슐화 = 헤더를 붙여나가는 과정

TCP/IP 4 layers

OSI 모델을 기반으로 실무에 맞춰 단순화된 모델

 

어플리케이션 계층
전송 계층
인터넷 계층
네트워크 인터페이스 계층

클라이언트와 서버 모두 응용 계층에서 동작함.

HTTP

표현헤더
협상헤더

HTTP/1.1, HTTP/2 = TCP 기반
HTTP/3 = UDP 기반

 

특징

• 클라이언트-서버 구조 (Request-Response)
• 무상태 프로토콜, 비연결성
• HTTP 메시지
• 단순함, 확장 가능

고객이 자신의 주문을 기억하고 있다
갑자기 클라이언트 요청이 증가해도 서버를 대거투입할 수 있다.
무상태는 응답 서버를 쉽게 바꿀 수 있다. -> 무한한 서버 증설 가능

상태 유지가 필요한 경우에는 브라우저 쿠키, 서버 세션, 토큰 등을 활용한다.
상태 유지는 최소한만 사용한다.

TCP/IP에서는 기본적으로 연결을 유지한다.
HTTP는 요청을 주고받을 때만 연결을 유지하고 응답을 주고 나면 TCP/IP 연결을 끊는다.

비연결성은 트래픽이 많고, 큰 규모의 서비스를 운영할 때에는 한계를 보인다.

 

한계

• 브라우저로 사이트를 요청하면 자바스크립트, CSS 파일 등이 다운로드됨. 매번 다시 다운로드하는 것은 비효율적. HTTP 지속 연결로 문제를 해결한다.

연결하고 끊고, 또 연결하고 끊고 반복이었음.
HTTP 지속 연결
지속 연결에서는 모든 자원에 대한 응답이 돌아온 후에 연결을 종료한다.

표현: 요청이나 응답에서 전달할 실제 데이터
표현 헤더: 표현 데이터를 해석할 수 있는 정보 제공 (데이터 유형, 길이, 압축 정보 etc)

<field-name> : <field-value>

Content-Type, Content-Encoding, Content-Language, Content-Length

요청에서 사용되는 헤더

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

• 웹 브라우저 정보 등등
• 어떤 종류의 브라우저에서 장애가 발생하는지 파악 가능
• 요청에서 사용

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

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

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

• 응답 헤더 Access-Control-Allow-Origin

Authorization: 인증 토큰을 서버로 보낼 때 사용하는 헤더

• 토큰의 종류 + 실제 토큰 문자 전송

응답에서 사용되는 헤더

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

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

Location: 페이지 리디렉션

• 상태 코드 3xx 에서는 응답의 결과에 따라 Location 헤더가 있으면 그 곳으로 자동 이동함
• 상태 코드 201(created): Location 값은 요청에 의해 생성된 리소스 URI

Allow: 허용 가능한 HTTP 메서드

• 405(Method Not Allowed)에서 응답에 포함.

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

• 503(Service Unavailable): 서비스가 언제까지 불능인지 알려줄 수 있음
• Retry-After: 120(초 단위 표기)

콘텐츠 협상 헤더

요청 시에만 사용!

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

선호하는 타입이 서버에 없을 경우를 대비해 우선순위를 지정할 수 있음.

HTTPS

대칭키, 비대칭키
HTTP Secure

요청과 응답으로 오가는 내용을 암호화.
HTTP에서는 데이터가 있는 그대로 전송됨.
-> 제 3자가 탈취하면 끝이다.

HTTPS 프로토콜로 보내면 데이터가 암호화된다.
제 3자에게 탈취되더라도 내용을 알아볼 수 없음.

암호화 방식

암호화할 때 사용할 키, 암호화한 것을 해석할 때 사용할 키 => 요 두 가지가 필요함.

1. 대칭 키 암호화

암호화와 복호화할 때 사용하는 키가 동일한 방식
연산 속도가 빠르다.
키를 주고 받는 과정에서 탈취당해버리면 암호화가 소용없어짐
키를 관리하는데 신경을 많이 써야 한다.

2. 공개 키(비대칭 키) 암호화 방식

암호화와 복호화할 때 사용하는 키가 다른 방식

두 개의 키를 각각 공개 키, 비밀 키라고 부름.
공개 키는 누구나 접근 가능, 비밀 키를 가진 사람만 내용을 복호화할 수 있음.
보통 사용자가 공개 키를, 서버가 비밀 키를 가짐.
비밀 키는 해킹당하지 않는 이상 탈취되지 않음.

대칭 키 방식보다 보안성이 더 좋음. 하지만 연산이 복잡해 더 많은 시간이 소요된다.

SSL/TLS 프로토콜

HTTP의 소켓 부분에서 서버 인증과 데이터 암호화가 진행됨.
SSL, TLS라는 프로토콜을 이용함.
SSL이 표준화되며 TLS로 이름이 바뀜. 사실상 같다고 보면 된다.

특징

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

CA?

Certificate Authority
CA로 서버의 정보와 공개 키를 전달하여 인증서를 받음.
CA가 인증서 발급

CA의 비밀 키로 암호화된 데이터는 CA의 공개 키로만 복호화가 가능
CA에서 발급한 인증서가 맞다면 복호화가 잘 되어야 함.

대칭 키 전달

모든 요청에서 공개 키 암호화 방식을 사용하는 것은 비효율적.
서버의 공개 키는 클라이언트와 서버가 함께 사용하게 될 대칭 키를 주고받을 때 쓰임.

클라이언트는 생성한 대칭 키를 서버와 공개 키로 암호화하여 전달함.
서버는 그 대칭 키를 서버의 비밀 키로 복호화하여 대칭 키를 확보한다.

이제 데이터는 대칭 키로 암호화되어 전달된다.
대칭 키 자체가 오고가지 않기 때문에 유실 위험이 없어짐.

HTTP + SSL/TLS = HTTPS

 

🔍 공부가 더 필요한 부분

mkcert에서 key와 cert의 차이 찾아보기

HTTPS 암호화 방식 글이나 영상 더 찾아보기