[CS 스터디] 2주차 네트워크

강아람·2022년 9월 9일

CS 스터디

목록 보기

3/5

📚 HTTP의 GET과 POST

📖 HTTP Protocol

protocol: 컴퓨터 내부에서, 또는 컴퓨터 사이에서 데이터의 교환 방식을 정의하는 규칙 체계
- 기기 간의 통신에는 교환되는 데이터 형식의 합의가 필요한데 이러한 형식을 정의하는 규칙 집합을 프로토콜이라 한다.

HTTP Request와 Response

HTTP 프로토콜은 클라이언트의 요청과 서버의 응답으로 데이터를 주고 받는다. 클라이언트는 서버에게 요청하는 데이터의 정보 등과 함께 요청의 목적이나 종류를 알리는 수단인 HTTP Method를 HTTP Request Message에 담아 요청을 보낸다.

📖 GET

존재하는 자원에 대한 요청

HTTP Request Message의 Header 부분의 url에 요청 데이터가 담겨 전송됨(Query String)
- 요청 데이터의 크기가 제한적
- url에 데이터가 노출되어 보안에 취약
GET method는 주로 데이터를 읽거나(Read) 검색(Retrieve)할 때 사용
GET 요청은 오직 데이터를 읽을 때만 사용하고 수정할 때에는 사용하지 않음
idempotent: 멱등 (여러 번 요청에도 같은 결과 반환)

📖 POST

새로운 자원을 생성

HTTP Request Message의 Body 부분에 요청 데이터가 담겨 전송됨
- GET 방식보다 요청 데이터의 크기 제한이 적음
- Body에 담기기 때문에 노출되지 않아 보안 측면에서 낫지만 암호화되지 않기 때문에 보안에 취약
주로 새로운 리소스 생성(create)에 사용
- 하위 리소스(부모 리소스의 하위 리소스) 생성에 사용됨
idempotent X: 멱등성이 없음 (같은 요청을 반복했을 때 항상 같은 결과를 보장하지 않음)

보안 방법

HTTP 프로토콜은 텍스트 교환 방식이기 때문에 GET, POST Message 모두 보안에 취약하다. 이러한 보안 문제를 해결해주는 것이 바로 HTTPS이다.

📖 HTTPS

HTTP: TCP ▶ HTTP
HTTPS: TCP ▶ SSL ▶ HTTP

HTTPS는 SSL 프로토콜을 추가하여 접속한 사이트가 신뢰할 수 있는 사이트인지 검증, 요청 데이터를 암호화하여 전송한다.

SSL(Secure Socket Layer) 프로토콜

= TLS(Transport Layer Security)

전송 데이터를 암호화하여 신뢰할 수 있는 인터넷 연결이 가능하게 해주는 프로토콜

SSL은 대칭키, 비대칭키를 암호화 방식으로 채택했다.

대칭키

동일한 키로 암호화와 복호화를 하여 데이터를 주고 받는다.
- 데이터를 암호화할 때 '123'이라는 key를 사용했다면 복호화할 때에도 '123'이라는 key를 사용해야 한다.
key를 공유하는 과정에서 key가 노출될 수 있다. ▶ 키 배송 문제 (Key Distribution Problem)

대칭키 문제 해결방법

1) 키의 사전 공유

사전에 키를 안전한 방법으로 서로 공유하는 방식

▶ 공격자가 중간에서 가로챌 위험이 있고, 사용자가 많아지면 관리할 키가 많아짐

2) 키 배포 센터

키 배포 센터에서 난수 생성기로 세션키를 생성하고 두 사용자의 비밀키로 세션키를 암호화하여 공유하면 두 사용자가 세션키를 복호화하여 사용하는 방식

▶ 사용자가 많아지면 키 배포 센터의 부하가 커지고, 키 배포 센터에 문제가 발생하면 사용자들의 암호화 통신에 문제가 생김

3) Diffie-hellman 키 교환

두 사용자가 공통의 숫자 2개를 공유하고 하나의 숫자를 선택해 식에 대입한 결과를 서로에게 전송하여 그 결과를 또 다른 식에 대입한 결과로 공통의 비밀키를 정하는 방식

▶ 비밀키를 계산하기 어려울 수 있고, 사용자 간의 인정 과정이 없어 중간자 공격에 취약

4) 비대칭키 사용

비대칭키

두 개의 키로 암호화와 복호화
: 공개키(Public key)와 개인키(Private Key)

1) 공개키 암호화

공개키로 암호화하고 개인키로 복호화하는 방식

사용자 A가 공개키 저장소에 저장된 사용자 B의 공개키로 데이터를 암호화하여 전송하면 사용자 B는 자신의 개인키로 데이터를 복호화

▶ 개인키로만 데이터 복호화가 가능하기 때문에 데이터의 보안을 강화할 때 사용

2) 전자 서명

개인키로 암호화하고 공개키로 복호화하는 방식

사용자 A가 자신의 개인키로 데이터를 암호화하여 사용자 B에게 전달하면 사용자 B는 공개키 저장소에 있는 사용자 A의 공개키로 데이터를 복호화

▶ 데이터의 보안에는 취약하나 보낸 사람이 확실(개인키)하기 때문에 사용자 인증 가능 (사용자 A의 공개키를 아는 사용자들은 모두 복호화가 가능)

👀 공개키를 공개해도 되는 이유

공개키를 통해 개인키를 찾을 수 없다고 판단하기 때문

실제로는 대칭키와 공개키 방식을 함께 사용
: 공개키 방식은 시간이 오래 걸리고 리소스를 더 많이 요구하기 때문

💻 HTTPS 통신을 위한 과정

Server가 SSL 인증서를 받는 과정

1) Server가 Key 생성 (Public Key - Private Key)
2) Server가 CSR(인증 서명 요청서) 생성(Public Key + Server info)하여 CA에 전송
3) CA가 SSL 인증서(Server info를 Private Key로 암호화하여) 발급
4) Server의 SSL 인증서 획득

CA(Certificate Authority): 인증서 발급 기관. 신뢰성이 엄격하게 공인된 기업들만 참여할 수 있음

HTTP Handshake

1) Client가 Server에게 SYN 패킷 전송(접속 요청) 후 SYN_SENT 상태(SYN/ACK 응답 대기)
2) Server는 ACK, SYN flag 패킷 전송(요청 수락) 후 SYN_RECEIVED 상태(ACK 응답 대기)
3) Client가 Server에게 ACK 패킷 전송

이 과정 이후 연결이 생성되고 데이터 통신 가능

SSL Handshake

1) TCP 연결이 완료되면 Client가 Client Hello 수행

Client Hello: 암호화 방식, 난수, SSL 버전 정보(, 세션 아이디)를 Server에 전송

2) Server는 Client Hello 패킷을 받고 Client에게 Server Hello 수행

Server Hello: 브라우저의 암호화 방식을 선택하여 SSL 인증서, 난수 전송

3) Client는 Premaster Secret 생성: Premaster Secret=Session Key

Server의 SSL 인증서 위조 여부 확인
SSL 인증서를 CA의 Public Key로 복호화(CA Public Key는 브라우저에 내장되어 있다)하여 SSL 인증서의 위조 여부 확인
Premaster Secret: Client의 난수와 Server에게 받은 난수를 Server의 Public Key로 암호화하여 Server에게 전달

세션키를 통해 HTTPS 통신 가능 (SSH Handshake 단계까지는 공개키 방식, 이후 HTTPS 통신은 대칭키 방식 사용)

출처:

📚 TCP 3-way Handshake & 4-way Handshake

(위에 내용이 있기 때문에 간단히 그림으로 대체 하겠습니당)

1) 1단계: Client가 연결 종료를 요청하는 FIN 패킷 전송
2) 2단계: Server는 FIN에 대해 확인 패킷 ACK 전송

Server가 데이터를 전송 중에 FIN 패킷을 받았다면 남은 데이터를 전송하는 동안 TIME_OUT 상태

4) 3단계: 데이터 전송이 끝나면 Client에게 FIN 패킷 전송
5) 4단계: Client는 FIN에 대한 확인 패킷 ACK 전송
6) Server는 ACK 패킷을 받았기 때문에 연결을 종료
7) Client는 아직 도착하지 못한 패킷을 염두하여 TIME_WAIT 상태로 대기
8) 일정 시간이 지나면 Client도 연결 종료

📚 TCP와 UDP의 비교

네트워크 프로토콜

Transport Layer

응용 계층과 네트워크 계층 사이에 존재하는 네트워크 구조의 핵심 역할을 하는 계층
서로 다른 호스트에서 동작하는 애플리케이션 프로세스 간의 논리적 통신 제공

Port 번호

동일한 컴퓨터 내에서 통신하고 있는 애플리케이션을 식별할 때 사용하는 애플리케이션 주소

전송 계층의 통신 방식과 프로토콜

연결형 통신: 신뢰할 수 있고 정확한 데이터를전달하는 통신 ▶ TCP 프로토콜
비연결형 통신: 효율적으로 데이터를 전송하는 통신 ▶ UDP 프로토콜

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

신뢰성있는 바이트 스트림 전송을 위한 프로토콜

TCP 프로토콜의 데이터 단위

Transport 계층의 패킷: 세그먼트

패킷

네트워크에서 전송되는 데이터의 단위

네트워크 계층(3)에서 정의되는 데이터의 단위

👀 네트워크 계층의 데이터그램을 패킷이라고 부르는 이유

패킷 교환 방식에서 라우터가 패킷의 경로를 확인할 때 데이터그램의 헤더의 목적지 IP를 사용하기 때문

TCP 통신 과정

1) TCP 연결 확립: 3-way Handshake

애플리케이션 간의 가상 통로를 만들어 데이터를 전송함으로써 애플리케이션 별 데이터의 흐름 관리 가능 ▶ 1:1 통신 가능
연결을 확립하는 과정에서 호스트 간의 합의를 통해 MSS가 결정하여 MSS 크기에 맞추어 데이터를 분할하고, 데이터의 순서 번호를 결정

2) 데이터 전송

송신: 수신 호스트에게 데이터를 전송한 후 확인 응답(ACK)을 일정 시간 기다리다 확인 응답이 오지 않을 경우 데이터 재전송 ▶ 신뢰성 확보
수신: 송신 호스트에게서 데이터를 받으면 수신 호스트는 반드시 송신 호스트에게 확인 ACK 패킷을 전송
- ACK: 수신 데이터의 순서 번호와 다음에 받을 데이터의 순서 번호를 알림

3) TCP 연결 해제: 4-way Handshake

TCP 흐름 제어

데이터 송신 후 수신자에게서 응답이 올 때까지 기다린다면 패킷 전송이 지연됨
▶ 흐름 제어를 통해 전송 효율 향상

윈도우 사이즈(수신 가능한 버퍼의 크기)

: 확인 응답을 기다리지 않고 송신할 수 있는 데이터의 크기, 한 번에 전송할 수 있는 전체 패킷의 크기

송신 호스트는 수신 호스트가 지정한 윈도우 사이즈만큼 수신 호스트의 확인 응답 없이도 전송 가능

🌟 TCP는 수신 호스트가 윈도우 사이즈를 변경하는 방법으로 송신 호스트에게 데이터 전송량을 지시함으로써 데이터의 흐름을 제어하고 전송 효율을 향상

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

호스트 간 연결 설정 없이 IP 데이터그램을 캡슐화하여 전송하는 프로토콜

UDP의 특징

1) 비신뢰성, 비연결성

흐름 제어, 오류 제어 X
손상 세그먼트의 수신에 대한 재전송 X
호스트 간의 연결 설정 X
2) Header에 송신자와 수신자의 Port 번호만 기입 (선택적으로 Checksum도 넣을 수 있으나 오류 복구에 사용하지는 않는다.....)

📖 TCP와 UDP의 비교

출처:

📚 DNS(Domain Name System)

도메인 이름을 사용했을 때 입력한 도메인을 실제 네트워크 상에서 사용하는 IP 주소로 바꾸고 해당 IP 주소로 접속하는 계층 구조 시스템

Domain Name: 숫자로만 구성된 IP 대신 사용할 수 있는 인터넷 주소

DNS 동작 방식

사용자가 'www.naver.com'을 주소창에 치면
1) 웹 브라우저는 local DNS server에게 도메인 이름에 대한 ip 주소 요청
2) local DNS server는 root DNS server에게 ip 주소 요청, root DNS Server에게 해당 도메인에 대한 정보가 없을 경우 TLD server의 주소를 전달
3) local DNS server는 TLD server에게 ip 주소 요청, TLD server에게 해당 도메인에 대한 정보가 없을 경우 하위 level의 DNS server 주소 반환
4) local DNS server는 도메인에 대한 ip 주소를 받을 때까지 이 과정을 반복(Iterative Query, Recursive Query)하고, 주소를 받으면 이 ip 주소를 캐싱한 후 웹 브라우저에게 전달

라운드 로빈(Round Robin) DNS

별도의 소프트웨어 혹은 하드웨어 로드밸런싱 장비를 사용하지 않고, DNS 만을 이용하여 도메인 레코드 정보를 조회하는 시점에서 트래픽을 분산하는 기법
지리적으로 웹 서버 간의 거리가 멀리 떨어져 있어 실시간으로 Health check가 어려울 경우 또는 적은 비용으로 구현이 필요할 때 사용

라운드 로빈 DNS 원리

사용자가 주소창에 도메인 주소를 입력하면 DNS는 도메인의 정보를 조회하는데, 이때 IP 주소를 여러 대의 서버 IP 리스트 중에서 라운드 로빈 형태로 랜덤하게 하나 또는 여러 개를 선택해 사용자에게 알려줌
▶ 웹 사이트에 접속하는 다수의 사용자는 여러 개의 웹 서버에 나뉘어 접속하게 되면서 서버의 부하가 분산

📖 라운드 로빈 DNS 방식의 문제점

서버 수 만큼 공인 IP 주소가 필요

부하 분산을 위해 서버의 수를 늘리기 위해서는 그만큼의 공인 IP가 필요하다.

균등 분산의 어려움

모바일의 경우 특정 프록시 서버(캐리어 게이트웨이)를 경유하는데 같은 프록시 서버를 경유하는 접속은 항상 같은 서버로 접속된다. 또한 PC의 경우에도 DNS 질의 결과를 브라우저가 캐싱하기 때문에
균등 부하 분산이 어려울 수 있다.

서버가 다운되었을 경우 확인 불가

DNS 서버는 웹 서버의 부하나 접속자 수 등을 감지할 수 없기 때문에 웹 서버가 다운되어도 이를 알지 못한 채 사용자에게 주소를 제공한다.

📖 문제 극복 방법

다중화 구성 방식 (Synchronous Time-Division Multiplexing)

AP 서버에 Virtual IP를 부여하여 다중화를 구현하는 방식

각 AP 서버의 Health check 후 이상이 감지되면 virtual ip를 정상 AP 서버로 인계하는 방식

가중치 편성 방식 (Weighted Round Robin)

각각의 웹 서버에 가중치를 주어 분산 비율을 변경하는 방식

가중치가 큰 서버수록 빈번하게 선택되므로 처리능력이 좋은 서버는 가중치를 높게 설정

최소 연결 방식 (Least Connection)

접속 클라이언트 수가 가장 적은 서버를 선택하는 방식

로드 밸런서에서 실시간으로 connection 수를 관리하거나 각 서버에서 주기적으로 접속자 수를 알리는 것이 필요

출처:

📚 브라우저에 url을 입력하면 일어나는 일

📖 브라우저

URL 파싱

url에 입력된 값을 분석하여그 의미에 따라 HTTP Request Message를 생성

HSTS List 확인

브라우저 내부에 존재하는 HSTS List에 해당 도메인이 존재하면 HTTPS Protocol로, 존재하지 않으면 요청 Protocol로 요청을 보냄

HSTS(Http Strict Transport Security)

: web site에 접속할 때 강제적으로 HTTPS Protocol로 접속하게 하는 기능

해당 사이트가 HTST 기능을 지원한다면 브라우저에 내장된 HSTS List에 해당 사이트 도메인과 함께 도메인 정보를 저장해두고, 다음에 그 사이트에 접속할 때에는 HTTPS 프로토콜로 접속 요청을 보냄

도메인에 대한 IP 주소 검색

DNS 서버에게 IP 주소를 요청하여 도메인을 IP 주소로 변환

HTTP Request Message 생성

url의 분석 결과를 토대로 HTTP Request Message를 만들어 웹 서버에게 전송

📖 프로토콜 스택과 LAN 어댑터

OS에 내장된 프로토콜 스택이 브라우저의 요청을 패킷에 저장하여 제어 정보(목적지 주소 등)와 함께 LAN 어댑터에게 전달
LAN 어댑터는 다음 어댑터(예. hub)의 MAC주소를 패킷에 더한 프레임을 전기 신호로 변환하여 LAN 케이블로 송출

📖 허브, 스위치, 라우터

LAN 어댑터가 송신한 프레임은 스위칭 허브를 경유하여 인터넷 접속용 라우터에 도착하고, 라우터는 패킷을 프로바이더에 전달하여 인터넷으로 넣어줌

📖 프로바이더

프로바이더(POP, Point Of Presence)는 인터넷 입구의 액세스 회선을 통해 온 패킷을 다른 POP으로 전달, 패킷은 목적지를 향해 이동

📖 게이트웨이

패킷이 웹 서버가 존재하는 네트워크의 관문인 게이트웨이에 도착하면 목적지 IP 주소를 MAC 주소로 변환 필요
해당 네트워크에서 ARP(Address Resolution Protocol)를 브로드캐스트 하면 해당 IP 주소를 가지는 노드가 자신의 MAC 주소를 전송

📖 방화벽, 캐시 서버

패킷이 웹 서버 측 LAN의 방화벽에 도착하면 방화벽, 캐시 서버가 패킷을 검사하여 웹 서버 안에 넣음

📖 웹 서버

패킷이 웹 서버에 (물리적으로) 도착하면 TCP 연결
연결이 완료되면 웹 서버의 프로토콜 스택은 패킷을 추출하여 메시지를 복원하고 웹 서버 애플리케이션에 전달
메시지를 받은 웹 서버 애플리케이션은 요청 메시지에 따른 데이터를 HTTP Response Message에 넣어 브라우저에 회신

출처:

강아람

이전 포스트

[CS 스터디] 1주차 자료구조

다음 포스트