데이터 구조, 한재엽님의 Part 1-3 Network를 기반으로 여러분들의 블로그를 참조!

03. Network

GET vs POST

HTTP 프로토콜을 이용해 서버에 요청하는 방식

GET

Request Header부분의 url에 담겨 요청 데이터 전달
url의 뒤에 ?를 붙인 후 필요한 데이터를 전달
전달하는 데이터가 url에 노출되므로 주의 필요
정보요청에 사용
브라우져에서 Caching 가능

POST

Request Body부분에 데이터를 담아 전송
서버의 값 변경 혹은 추가

3-way-handshake

Three way handshake

TCP/IP 프로토콜을 통한 응용프로그램 데이터 전송 이전의 세션 수립 과정

Client -> Server : SYN
Server -> Client : SYN ACK
Client -> Server : ACK

TCP와 UDP의 비교

UDP

UDP(User Datagram Protocol, 사용자 데이터그램 프로토콜)
비연결형 프로토콜
UDP는 흐름제어, 오류제어, 손사된 세그먼트 재수신기능을 수행하지 않음
TCP대비 간단
사용예
- DNS : IP주소를 찾기위해 DNS서버로 UDP패킷을 통해 HOST NAME을 포함한 패킷을 전송 -> 서버는 응답을 바탕으로 IP주소를 포함한 UDP패킷으로 응답.

TCP

TCP(Transmission Control Protocol, 전송제어 프로토콜)
신뢰성, 순차적 전달을 위함
송수신자 모두 ‘소켓’이라는 종단점을 생성
TCP 연결은 3-way-handshake

HTTP와 HTTPS

HTTP의 문제점

HTTP는 평문 통신(도청 가능)
통신 상대를 확인하지 않으므로 위장이 가능
완전성을 증명할 수 없으므로 변조가 가능

도청이 가능한 TCP/IP

패킷 수집만으로 도청이 가능
평문 통신의 경우 정보가 그대로 노출되므로 암호화 통신 필요

보안 방법

통신 자체의 암호화
- HTTPS(HTTP Secure): HTTP + SSL(Secure Socket Layer)
- TLS프로토콜을 HTTP와 조합
콘텐츠의 암호화
- HTTP를 사용하되, 중요한 정보를 암호화 하여 전달
- 전달자: 암호화 / 수신자:복호화 과정이 필요

통신 상대 위장

HTTP기반의 통신에서는 통신 상대의 확인 프로세스가 없어 누구나 리퀘스트 가능
IP/포트번호 등을 통해 웹서버 자체의 제한이 없을 경우 무조건 리스폰스를 반환
- 전달받은 리스폰스가 ‘진짜 서버’가 ‘진짜 보내고 싶었던 내용’인지 확인할 수 없음
- 전달받은 리퀘스트가 ‘진짜 클라이언트’가 ‘진짜 보내고 싶었던 내용’인지 확인할 수 없음
- 통신 중인 상대의 접근 허가 여부를 파악할 수 없음
- 리퀘스트 주체가 누구인지 할 수 없음
- 어떤 리퀘스트든 우선 받게 됨(DDos 공격에 취약)

보안 방법

SSL을 통해 상대방 확인 가능
- 증명서를 이용하여 상대를 확인하며, 증명서는 3자 기관에 의해 검증

내용 위조

클라이언트가 수신한 내용이 송신측이 보낸 내용과 일치함을 보장할 수 없음
공격자에 의해 리퀘스트나 리스폰스가 중간에 변조되는 중간자공격(Man-in-the-Middle)에 취약

보완 방법

해시 알고리즘을 통한 해시값 생성
디지털 서명 등의 방법 존재
HTTPS사용

HTTPS

SSL로 둘러 쌓인 HTTP
HTTP <-> TCP에서 HTTP -> SSL <-> TCP의 흐름
SSL에 의해 암호화, 증명서, 안전성 보호를 이용 가능
HTTPS에서 사용하는 SSL의 암호화 방식 : 하이브리드 암호화 방식 (공개키 암호화 방식 + 대칭키 암호화 방식)
- 공개키 방식 : 해당 블로그 참조
  - 송신(공개키로 암호화) -> 수신(개인키로 복호화): 개인키를 가진 수신자만 데이터에 접근이 가능하므로 보안이 중요한 경우 사용
  - 송신(개인키로 암호화) -> 수신(공개키로 복호화): 송신자가 보낸 데이터의 신뢰성 보장을 위해 사용
  - SSL인증서를 이용하여 상호 신원 확인 및 키교환 수행
  - SSL인증서는 클라이언트가 서버에 접속 직후 내려받아 검증 후 통신
  - SSL인증서는 CA(Certificate Authority)로 부터 발행되며, CA의 개인키로 서버의 공개키를 암호화하여 발행
    - [공개키 part]
      - 모든 브라우져는 인증된 CA들의 공개키를 가지고 있으며, 이를 통해 인증서 검증
      - 인증서 복호화 시 복호화 되는 서버의 공개키를 이용하여 암호화 요청(pre master secret)을 서버에 보냄
    - [대칭키 part]
      - 서버는 개인키를 통해 클라이언트의 암호화된 요청을 검증하며 클라이언트가 보낸 pre master secret을 획득
      - 이를 바탕으로 session key를 만들고 이것을 이용하여 암호통신

모든 페이지에서 HTTPS를 사용하지 않는 이유

HTTPS는 암호화/복호화의 과정을 반드시 거치기 때문에 상대적으로 리소스가 더 많이 필요
하지만, - HTTPS는 필수!!
HTTPS에서는 HTTP/2를 지원하여 심지어 더 빠름
- HTTP보다 HTTPS가 더 빠르다에 대한 자세한 정보

DNS round robin 방식

DNS round robin 방식의 문제점

서버 수 만큼 공인 IP가 필요함
- 부하 분산을 위한 서버 확장 만큼 공인 IP가 필요
균등한 분산이 이루어지지 않음
- 스마트폰을 통해 접속하는 모바일 페이지의 경우 통신사의 캐리어 게이트웨이(프록시 서버)에서 일정시간 동일한 ip를 돌려줌
- 따라서 의도와 다르게 부하 분산이 이루어지지 않을 수 있음
- PC용 페이지 역시 DNS결과를 캐싱하는 경우 동일
- DNS 레코드의 TTL값을 짧게 설정할 수 있으나 제한적임
서버 다운시 확인 불가
- DNS 서버 자체는 웹 서버의 부하나 접속 수등의 상황에 대한 컨트롤 불가
- 웹 서버의 높은 부하로 응답이 느려지는 등의 문제가 생긴 경우에도 계속 로직대로 IP를 제공

Round Robin 방식의 문제를 해결하기 위한 DNS 스케줄링 알고리즘이 존재
- weighted round-robin
  - 각 웹서버마다 가중치를 가미하여 분산 비율을 결정
  - 처리용량이 큰 서버의 IP가 더 많은 사용자에게 제공됨
- least-connection
  - 접속 중인 클라이언트 수가 가장 적은 서버를 선택
  - 로드밸런서에서 실시간으로 connection 수를 관리하거나 혹은 각 서버에서 주가적으로 connection수를 알림

웹 통신의 큰 흐름

브라우저

url에 입력된 값을 브라우저 내부에서 결정된 규칙에 따라 그 의미를 조사
조사된 의미에 따라 HTTP Request 메시지를 만듦
만들어진 메시지를 웹 서버로 전송 위의 메시지는 브라우저가 OS에 의뢰하여 전송

프로토콜 스택, LAN 어댑터

프로토콜 스택(운영체제 내장 네트워크 제어용 SW)이 브라우저로부터 메시지 수신
메시지를 패킷에 저장
수신처 주소 등 제어 정보 추가
패킷을 LAN 어댑터에 전달
LAN어댑터에서 패킷을 전기신호로 변환
LAN케이블로 신호 전달
- 프로토콜 스택에서는 통신중 오류 발생시 제어정보를 사용하여 고치거나, 상황을 조절 하는 등의 역할 수행
- 비서의 역할과 비슷

허브, 스위치, 라우터

LAN 어댑터에서 송신한 패킷이 스위칭 허브등을 경유하여 라우터에 도달
라우터는 패킷을 통신사에 전달
인터넷에 접속

액세스 회선, 통신사

패킷은 인터넷의 입구에 있는 액세스 회선(통신 회선)에 의해 POP(Point of Presence, 통신사용 라우터)까지 운반
POP를 거쳐 인터넷의 핵심에 도달
대형 라우터들을 거쳐 패킷이 목적지로 이동

방화벽, 캐시서버

패킷은 웹 서버 측의 LAN에 도달
방화벽에서 패킷을 검사
패킷이 웹 서버에 전달되어야 하는지 판단하는 캐시 서버 존재 굳이 웹서버 까지 가지 않아도 되는 경우 판별, 액세스한 페이지의 데이터가 이미 캐시서버에 존재할 경우, 웹서버를 거치지 않음

웹 서버

패킷이 웹 서버에 도착하게 되면 웹 서버의 프로토콜 스택은 패킷을 추출, 메시지를 복원하여 웹 서버 애플리케이션에 전달
웹 서버 어플리케이션은 요청 메시지에 따른 응답을 생성, 클라이언트로 response
반복