[CS] 네트워크

바인하·2022년 4월 4일

HTTP의 GET과 POST 비교

[참고]
https://hongsii.github.io/2017/08/02/what-is-the-difference-get-and-post/

GET : 서버로부터 정보 조회

요청하는 데이터가 Header 부분에 url이 담겨서 전송된다.
url 이라는 공간에 담겨가므로 전송할 수 있는 데이터 크기가 제한적
데이터가 url 에 그대로 노출되므로 보안이 필요할 땐 사용하면 안됨
서버에서 데이터를 가져와서 보여주는 용도 (SELECT 성격)
브라우저에서 caching 가능하므로 post 보다 빠름
- js/css/이미지와 같은 정적컨텐츠는 데이터 양이 크고, 변경될 일이 적어서 반복해서 동일한 요청을 보낼 필요가 없음
  → 정적 컨텐츠를 요청하면 브라우저에서 요청 캐시해두고, 동일한 요청 발생 시 캐시된 데이터 사용
Idempotent 멱등하게 설계 (설계원칙에 따라 서버의 데이터나 상태를 변경시키지 않아야 멱등하기 때문에 주로 조회시 사용)

POST : 리소스 생성/변경하기 위해 설계

데이터가 Body 부분에 담겨서 전송
데이터 크기가 GET 방식보다 크고 보안면에서 나음 (Body는 길이의 제한 없이 데이터 전송 가능)
서버의 값이나 상태 변경 or 추가
Non-idempotent 하게 설계

Idempotent(멱등) : 동일한 연산을 여러번 수행하더라도 동일한 결과가 나타나야 함

TCP 3-way Handshake

[참고]
https://asfirstalways.tistory.com/356

요청과 응답에 대한 패킷을 주고 받아야 하므로 두 종류의 패킷 존재
SYN 패킷을 보낼 때 Sequence Number에 랜덤한 숫자가 담기는 이유는?
- connection을 맺을 때 사용하는 포트는 유한 범위 내에서 사용하고, 시간이 지남에 따라 재사용되므로 과거에 사용된 포트번호 쌍을 사용하는 가능성이 존재한다. 서버 측에서는 패킷의 SYN을 보고 패킷을 구분하는데, 난수가 아닌 순차적 숫자가 전송되면 이전 connection으로부터 오는 패킷으로 인식할 수 있다. 이런 문제의 가능성을 줄이기 위해 난수로 ISN 설정하는 것

TCP와 UDP의 비교

UDP (User Datagram Protocol, 사용자 데이터그램 프로토콜) : 비연결형 프로토콜

즉, 인터넷 상에서 서로 정보를 주고받을 때 정보를 송신, 수신하는 신호 절차를 거치지 않고 / 보내는 쪽에서 일방적으로 데이터를 전달하는 통신 프로토콜

1. IP 데이터그램을 캡슐화하여 보내는 방법

여기서 데이터그램이란? IP의 전송단위, 독립적인 관계를 갖는 패킷
- 65,536 Byte인 가변길이 패킷으로, 헤더와 데이터 부분으로 구성됨

IP 데이터그램 캡슐화란?

1. 패킷이 TCP/IP 프로토콜 스택을 통해 이동함에 따라 각 계층의 프로토콜은 기본 헤더에서 필드를 추가하거나 제거함
2. 송신 시스템의 프로토콜이 패킷 헤더에 데이터를 추가하면 이 프로세스를 데이터 캡슐화

1. 상위 계층 메시지는 TCP나 UDP 메시지로 패키징되고 그것은 다시 IP 데이터그램의 페이로드 (전송의 근본적인 목적이 되는 데이터의 일부분) 가 된다.
2. IP 데이터그램은 2계층으로 전달되어 LAN, WAN, WLAN 프레임으로 캡슐화된다.
3. 그리고 물리 계층에서 비트로 변환되어 전송

2. 연결 설정을 하지 않고 보내는 방법

흐름제어, 오류제어 또는 손상된 세그먼트의 수신에 대한 재전송 하지 않음

→ 포트들을 사용하여 IP 프로토콜에 인터페이스를 제공하는 것

코드가 간단하며 TCP처럼 초기설정에서 요구되는 프로토콜보다 적은 메시지가 요구됨

UDP의 예 : DNS

어떤 호스트 네임의 IP주소를 찾는 프로그램은 DNS 서버로 호스트 네임을 포함한 UDP 패킷을 전송
서버는 호스트의 IP주소를 포함한 UDP 패킷으로 응답
사전 설정, 후 해제 필요 없음

DNS서비스가 UDP를 사용하는 것이 적합한 이유

연결의 시작과 끝 설정이 없다
- DNS 는 신뢰성보다 속도가 중요하다
연결 상태를 유지할 필요가 없다
- UDP는 어떠한 정보도 기록하지 않으며 유지할 필요가 없음
  → 특정 애플리케이션에 할당된 서버는 UDP에서 동작할 때 더 많은 클라이언트를 수용할 수 있다.

도메인 네임 -> IP 로 변경함으로 항상 많은 클라이언트를 수용하는 DNS 서버에게는 
연결 상태를 유지하지 않아 정보 기록을 최소화하는 UDP 가 적절하다.

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

신뢰성과 순차적인 전달을 필요로 하기에 탄생한 것
신뢰성 없는 인터넷을 통해 종단간에 신뢰성 있는 바이트 스트림을 전송하도록 설계됨
→ 바이트 스트림 : 한번에 한 바이트씩 연속적으로 전송되는 데이터의 흐름과 같이 끊임없이 연속되는 바이트 열
각 데이터 간의 구분을 의미적으로 구분하지 않고, 단순히 바이트들의 연속적인 흐름을 보고, 이들을 묶어 세그먼트화하여 전송
- 세그먼트화 처리 : 데이터를 패키징 처리
- 바이트들을 모아서 세그먼트화 하고 이에 TCP헤더를 붙이고, 순서를 제어한다!

- UDP 에서 프로세스는 미리 정해진 크기 이내의 메시지를 만들어 각각 자신의 헤더에 붙이고, 전송을 위해 IP에게 전달됨
→ 이 때, 각 메시지를 사용자 데이터그램이라고 함
- 궁극적으로 하나의 IP 데이터그램이 되고, 데이터그램들 간의 연관성을 따지지 않음

송신, 수신자 모두가 소켓이라는 종단점을 생성함으로써 이루어짐
연결 설정은 3-way handshake로 행해짐
모든 TCP 연결은 전이중 (full-duplex), 점대점 (point to point) 방식
- 전이중 : 전송이 양방향으로 동시에 일어날 수 있음을 의미
- 점대점 : 각 연결이 정확히 2개의 종단점을 가짐
멀티캐스팅, 브로드캐스팅 지원하지 않음

1. 멀티캐스팅

UDP를 기반으로 하나 이상의 송신자들이 특정한 하나 이상의 수신자들에게 데이터를 전송하는 방식
데이터를 수신받기 원하는 특정 호스트들에게만 전송 가능

2. 브로드캐스팅

UDP를 기반으로 자신의 호스트가 속해있는 네트워크 전체를 대상으로 패킷을 전송하는 일대다 통신방식
그들의 의사와 상관없이 모두 보내는 방식

HTTP와 HTTPS

[참고]

HTTP의 문제점

평문 통신이기 때문에 도청 가능

통신 상대 확인 안하므로 위장 가능

완전성 증명할 수 없기에 변조 가능

1. 평문 통신이기 때문에 도청 가능

HTTP 를 사용한 request, response 통신 내용은 HTTP 자신을 암호화하지 않으므로 통신 전체가 암호화되지 않음
TCP/IP는 도청 가능한 네트워크
- 네트워크 상의 패킷을 수집하는 것만으로도 도청 가능
- HTTP + SSL(Secure Socket Layer) or TLS(Transport Layer Security) = HTTP 통신 내용 암호화 가능
  → SSL을 조합한 HTTP를 HTTPS(HTTP Secure) or HTTP over SSL 이라고 함
- 통신 암호화 : SSL 등을 이용해 안전한 통신로 확립 후 해당 통신로로 HTTP 통신
- 콘텐츠 암호화 : 통신하고 있는 콘텐츠 내용 자체를 암호화, 즉 HTTP 메시지에 포함되는 콘텐츠만 암호화

2. 통신 상대 확인 안하므로 위장 가능

HTTP 를 사용한 request, response 에서는 통신 상대를 확인하지 않음
( request를 보낸 서버가 정말 URI에 지정된 호스트인지, response를 반환한 클라이언트가 request 를 출력한 클라이언트인지 확인 불가 )
누구나 request 가능
- request 보낸 웹서버가 원래 의도한 response를 보내야 하는 웹서버인지 확인할 수 없어 위장 우려
- response를 반환한 곳의 클라이언트가 원래 request를 보낸 클라이언트인지 확인할 수 없어 위장한 클라이언트 가능성 존재
- 통신하는 상태가 접근이 허가된 상대인지 확인할 수 없음
의미없는 request도 수신 → DoS 공격 방지 불가

<보완 방법>
SSL은 상대를 확인하는 수단으로 증명서를 제공함
증명서는 신뢰가능한 제 3자 기관에 의해 발행되기 때문에 서버, 클라이언트가 실재한다는 사실을 증명

3. 완전성 증명할 수 없기에 변조 가능

완전성 = 정보의 정확성
서버 또는 클라이언트에서 수신한 내용이 송신측이 보낸 내용과 일치한다는 것을 보장할 수 없음
공격자가 도중에 request, response를 빼앗아 변조하는 공격을 중간자 공격(Man-in-the-Middle) 이라고 함

<보완 방법>

MDS, SHA-1 과 같이 해시값을 확인하거나 파일의 디지털 서명을 확인하는 방법이 존재하지만 확실한 방법은 아님
확실하려면 HTTPS 사용해라

HTTPS = SSL의 껍질을 쓴 HTTP
HTTP에 암호화와 인증, 완전성 보호를 더한 HTTPS

HTTPS 는 새로운 애플리케이션 계층 프로토콜이 아니라, HTTP 통신을 하는 소켓 부분을 SSL 또는 TSL 이라는 프로토콜로 대체하고 있음

HTTP : TCP 와 직접 통신
HTTPS : (HTTP <> SSL) + (SSL <> TCP)

HTTPS의 SSL에서는 공통키를 공개키 암호화 방식으로 교환한 다음, 이후의 통신은 공통키 암호를 사용하는 방식인 하이브리드 암호 시스템을 사용
→ 공개키가 데이터를 제공한 사람의 신원을 보장해주는 것

** SSL 인증서

클라이언트가 접속한 서버가 신뢰할 수 있는 서버임을 보장
SSL 통신에 사용할 공개키를 클라이언트에게 제공

<SSL 인증서가 서비스를 보증하는 방법>
1. 웹 브라우저가 서버에 접속할 때, 서버는 가장 먼저 인증서 제공
2. 브라우저는 이 인증서를 발급한 CA가 자신이 내장한 CA 리스트에 있는지 확인
3. 서버를 통해 다운받은 인증서가, 내장된 CA 리스트에 포함되어 있다면 해당 CA의 공개키를 이용해 인증서 복호화

(참고) CA (Root Certificate) : 인증서는 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지 보장하는 역할, 이 역할을 하는 민간기업

클라이언트가 메시지 송신하며 SSL 통신 시작
( 메시지에 SSL 버전 지정, 암호 스위트라 불리는 리스트_사용하는 암호화 알고리즘 또는 키 사이즈 등, 포함 )
서버가 SSL 통신 가능한 경우 메시지로 응답
클라이언트와 마찬가지로 SSL 버전, 암호 스위트 포함
_ 서버의 암호 스위트 내용은 클라이언트에서 받은 암호 스위트의 내용에서 선택된 것
서버가 Certificate 메시지 송신, 메시지에는 공개키 증명서 포함
서버가 Server Hello Done 메시지를 송신하여 최초의 SSL 네고세이션 끝남을 통지
클라이언트가 Client Key Exchange 메시지로 응답, 메시지에는 통신 암호화하는데 사용하는 Pre-Mastersecret 이 포함
- 이 메시지는 (3)의 공개키 증명서에서 꺼낸 공개키로 암호화되어 있음
Change Ciper Spec 메시지 송신, 메시지 이후의 통신은 암호키를 생성해서 진행한다는 것을 나타냄
Finished 메시지 송신, 메시지는 접속 전체의 체크값을 포함하고 있음
네고시에이션 성공 여부는 서버가 이 메시지를 올바르게 복호화할 수 있는지에 따라 결정됨
서버도 Change Ciper Spec 메시지 송신
서버도 Finished 메시지 송신
서버와 클라이언트의 finished 메시지 교환 이후, SSL에 의해 접속이 확립됨.
애플리케이션 계층의 프로토콜에 의한 통신 시작으로 HTTP request 송신
HTTP response 송신
클라이언트가 접속을 끊음

** 모든 웹페이지에서 HTTPS를 써도 되는가?

평문 통신에 비해 암호화 통신은 CPU, 메모리 등 더 많은 리소스 요구
하지만 최근에는 하드웨어의 발달로 HTTPS 를 사용하더라도 속도 저하 일어나지 않으며, HTTP 2.0 사용 시 HTTPS 가 HTTP보다 빠르게 동작

DNS Round Robin 방식

[참고]

1. DNS 란?

ex) 네이버에 접속하려고 한다!

네이버의 IP 주소 알고 있어야 하고, 그 주소로 접속해야 함
우리는 www.naver.com 으로 접속하는데, DNS Server 는 naver.com 이 가리키는 IP를 브라우저에게 반환 (DNS Server = 웹 서버 주소에 해당하는 IP 주소 테이블을 가지고 있는 서버)

DNS 과정
- DNS 서버에서 도메인 네임으로 IP 를 받아옴
- 이 때, Domain Name Server에 접속하는 유저에 대해 Round Robin 방식으로 IP를 할당
- IP를 받아온 유저는 request 메시지 발송을 통해 정상적인 네트워크 통신 실시

2. 라운드 로빈 스케줄링 (Round Robin Schededuling) 이란?

별도의 소프트웨어 or 하드웨어 로드밸런싱 장비를 사용하지 않고, DNS만을 이용하여 도메인 레코드 정보를 조회하는 시점에서 트래픽을 분산하는 기법

Round Robin : DNS 서버 구성 방식 중 하나

시분할 시스템을 위해 설계된 선점형 스케줄링의 하나, 프로세스들 사이에 우선순위를 두지 않고, 순서대로 시간단위로 CPU를 할당하는 방식의 CPU 스케줄링 알고리즘
- 각 프로세스에 일정 시간 할당, 할당된 시간 지나면 그 프로세스는 잠시 보류한 후 다른 프로세스에게 기회를 줌 / 이런식으로 돌아가며 기회를 부여하는 운영방식

→ DNS 서버에 대한 Round Robin 형식으로 구성할 경우 로드밸런서가 필요 없음 (즉, 부하에 대한 걱정할 필요 없음)
자동적으로 시간에 따라 스케줄링이 변환되기 때문!

웹 서비스를 담당할 여러 대의 웹 서버는 자신의 공인 IP를 가짐
접속을 원하는 사용자가 해당 도메인 주소를 브라우저에 입력하면, DNS 는 도메인 정보를 조회
이 때 IP주소를 여러 대의 서버 IP 리스트 중에서 라운드 로빈 형태로 랜덤하게 하나 혹은 여러 개를 선택하여 사용자에게 알려줌
→ 웹 사이트에 접속하는 다수의 사용자는 실제로 복수의 웹 서버에 나뉘어 접속하며 자연스럽게 서버의 부하가 분산되는 방식

<단점>
1. 서버의 수만큼 공인 IP 주소 필요
2. 균등하게 분산되지 않음

스마트폰의 접속은 캐리어 게이트웨이라는 프록시 서버를 경유하는데, 프록시 서버는 이름변환 결과가 일정시간동안 캐싱되므로 같은 프록시 서버를 경유하는 접속은 항상 같은 서버로 접속됨
PC용 웹 브라우저도 DNS 질의 결과를 캐싱하므로 균등한 부하 분산 안됨
DNS 레코드의 TTL값을 짧게 설정함으로써 어느정도 해소가 되지만, TTL에 따라 캐시를 해제하는 것은 아니므로 주의 필요
- DNS 레코드 : DNS에 받은 요청을 어떻게 처리할 것인지에 대한 정보
- TTL : 다음 레코드 변경사항이 적용될 때까지 걸리는 시간을 결정하는 DNS 레코드 값

ex) TTL = 3600, 향후 레코드를 업데이트할 경우, 변경사항이 적용될 때까지 한시간이 소요됨.

서버가 다운돼도 확인 불가능

DNS 서버는 웹 서버의 부하, 접속 수 등의 상황에 따라 질의 결과를 제어할 수 없음 / 제어할 수 없으므로 어떤 원인으로 다운된지 검출하지 못하고 유저들에게 제공됨

<극복방법>

가중치 편성 방식 (Weighted Round Robin)
- 각각의 웹 서버에 가중치를 더해 분산 비율을 변경
- 가중치가 클수록 빈번하게 선택되므로, 처리 능력이 높은 서버는 가중치를 높게 설정하자
최소 연결 방식 (Least Connection)
- 접속 클라이언트 수가 가장 적은 서버 선택
- 로드밸런서에서 실시간으로 connection 수 관리하거나, 각 서버에서 주기적으로 알려주는 것이 필요

웹 통신의 큰 흐름

[참고]

https://joonfluence.tistory.com/96

우리가 Chrome 을 실행시켜 주소창에 특정 URL 값을 입력시키면 어떤 일이 일어나는가?

1. 브라우저

URL에 입력된 값을 브라우저 내부에서 결정된 규칙에 따라 의미를 조사
조사된 의미에 따라 HTTP Request 메시지 생성
만들어진 메시지를 웹 서버로 전송

이 때, 메시지 전송은 브라우저가 하는 것 아님!
- 브라우저는 메시지를 네트워크에 송출하는 기능 없음
→ OS 내부에 있는 네트워크 제어용 소프트웨어 (프로토콜 스택) 을 호출!
- OS에 송신 의뢰시, 도메인 명이 아니라 IP 주소로 메시지 받을 상대 지정해야 함
- 이 과정에서, DNS 서버를 조회해야 함

ex) 택배 직접 보내는 게 아니라 택배회사를 이용해 보내는 것

2. 프로토콜 스택, LAN 어댑터

프로토콜 스택이 브라우저로부터 메시지를 수신
받은 메시지를 패킷 속에 저장
수신처 주소 등의 제어정보 덧붙임
패킷을 LAN 어댑터에 넘김
LAN 어댑터는 다음 Hop 의 MAC 주소를 붙인 프레임을 전기 신호로 변환
신호를 LAN 케이블에 송출

프로토콜 스택 : 데이터 통신에 활용되는 프로토콜의 구조에 관한 개념으로, 계층화된 구조로 모여 있는 프로토콜의 집합
- 통신 중 오류 발생시, 제어 정보를 사용하여 고치거나 각종 상황을 조절하는 등의 역할을 함.
Application 계층 : 송수신측 사이에 주고받는 서비스에 따라 응용 계층의 프로토콜이 달라짐
ex) 웹 브라우저가 웹 서버에 요청한 데이터가 HTML 문서라면 HTTP 프로토콜 사용 → GET, POST 와 같은 HTTP 메소드, 네트워크상 자원의 위치를 나타내는 정보인 URL, 사용하는 HTTP 버전 정보와 함께 정보를 요청
Transport 계층 : 데이터 전송의 신뢰성을 보장하기 위한 계층, 송신 측에서 수신 측으로 패킷이 정상 전달되었는지 확인하는 역할 수행
- 네트워크 계층 : 데이터를 원하는 목적지로 전송하는 역할

- 송수신 기기 사이에는 라우터라는 네트워크 장비가 있는데, 데이터 패킷들이 이들을 거쳐 수신 측으로 전달됨.
- 라우터 : 데이터 목적지가 정해지면, 해당 목적지까지 어떤 경로로 가는 것이 효율적인지 파악 
- 라우팅 : 목적지 IP 주소까지 어떤 경로를 거쳐 데이터를 보낼지 결정하는 것

데이터 링크 계층 : 앞선 계층을 거친 후에는 서버의 LAN (건물 안이나 특정 지역을 범위로 하는 지엽적인 네트워크) 까지 도착한 것이다.

- LAN에서 데이터를 정상적으로 주고 받기 위해 네트워크 장비 간에 신호를 주고받는 규칙을 정하게 된다. 
  이 때, 가장 많이 사용되는 규칙이 이더넷
  	- 이더넷 : 스위치나 허브 (컴퓨터들을 LAN에 접속시키는 네트워크 장치)에서 데이터를 주고 받는 규칙을 전송
- 송/수신 측에 경로가 결정되면, 링크 계층은 한 노드에서 인접한 노드로 패킷을 보내기 위한 역할을 한다.

물리 계층 : 컴퓨터와 네트워크 장비를 연결하고, 컴퓨터와 네트워크 장비 간에 전송되는 데이터를 전기 신호로 변환하는 계층

3. 허브, 스위치, 라우터

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

4. 액세스 회선, 프로바이더

패킷은 인터넷 입구의 액세스 회선(통신 회선)에 의해 POP(Point Of Presence, 통신사용 라우터)까지 운반
- POP : 둘 이상의 서로 다른 네트워크 또는 통신 장치가 서로 연결되는 지점 / 주로 다른 장치에 연결하여 인터넷과의 연결을 설정하는데 도움이 되는 액세스 포인트, 위치 또는 시설
POP를 거쳐 인터넷의 핵심부로 들어감
수많은 고속 라우터들 사이로 패킷이 목적지를 향해 흘러감

5. 방화벽, 캐시서버

패킷은 인터넷 핵심부를 통과하여 웹 서버측의 LAN에 도착
기다리고 있던 방화벽이 도착한 패킷을 검사
패킷이 웹 서버까지 가야하는지 판단하는 캐시서버가 존재
(굳이 서버까지 가지 않아도 되는 경우를 필터링하여, 액세스한 페이지 데이터가 캐시 서버에 있으면, 웹 서버에 의뢰하지 않고 바로 데이터 읽음)

6. 웹 서버

패킷이 물리적인 웹 서버에 도착하면, 웹 서버의 프로토콜 스택은 패킷을 추출하여 메시지를 복원하고 웹 서버 애플리케이션에 넘김
메시지를 수신한 웹 서버 애플리케이션은 요청 메시지에 따른 응답 메시지를 넣어 클라이언트로 회송
왔던 방식대로 응답메시지가 클라이언트에게 전달

바인하

되면 한다

이전 포스트

[CS] 자료구조

다음 포스트

[CS] 네트워크

HTTP의 GET과 POST 비교

GET : 서버로부터 정보 조회

POST : 리소스 생성/변경하기 위해 설계

TCP 3-way Handshake

TCP와 UDP의 비교

HTTP와 HTTPS

1. 평문 통신이기 때문에 도청 가능

2. 통신 상대 확인 안하므로 위장 가능

3. 완전성 증명할 수 없기에 변조 가능

DNS Round Robin 방식

1. DNS 란?

2. 라운드 로빈 스케줄링 (Round Robin Schededuling) 이란?

<극복방법>

웹 통신의 큰 흐름

1. 브라우저

2. 프로토콜 스택, LAN 어댑터

3. 허브, 스위치, 라우터

4. 액세스 회선, 프로바이더

5. 방화벽, 캐시서버

6. 웹 서버

[CS] 자료구조

운영체제

0개의 댓글