나만의 언어로 CS 지식 정리하기 : 네트워크

2022년 10월 8일

#CS

1. HTTP의 GET과 POST

GET과 POST 모두 HTTP 프로토콜을 이용해 서버에 무엇인가를 요청할 때 사용하는 메서드입니다. GET, POST, PUT, PATCH, DELETE 모두 목적에 맞게 사용해야 합니다!

GET

GET은 HTTP Request Message 의 Header에 url이 담겨서 전송되는데요, 때문에 url 뒤 ? 에 파라미터로 데이터가 붙어서 request를 보내게 됩니다.

이러한 방식은 url이라는 공간에 담겨가기 때문에 전송할 수 있는 데이터의 크기가 제한적이라는 특징이 있습니다 또 보안이 필요한 데이터에 대해서는 url에 그대로 데이터가 노출되기 때문에 GET 방식은 적절하지 않습니다! (EX. 계정 로그인 관련)

POST

POST는 HTTP Request Message의 Body 부분에 데이터가 담겨서 전송이 됩니다. 때문에 데이터가 크거나 보안을 신경써야 하는 경우 POST 방식이 적절하다고 합니다. (+ 하지만 클라이언트 측에서는 GET, POST 방식 모두 요청되는 데이터가 노출되므로 암호화를 하는 것을 추천한다고 합니다!)

GET은 데이터를 가져오고, POST는 데이터를 생성합니다. 서버의 값을 변경하거나 추가하기 위해 사용되는 메서드입니다.

또한 GET 메서드는 브라우저에 데이터를 캐싱합니다. 따라서 POST 방식으로 보내야 하는 데이터를 GET 방식으로 요청한다면 캐싱되어 있던 데이터가 응답될 가능성이 있습니다.

이런 이유로 목적에 맞는 메서드를 선택하는 것이 중요해 보입니다.

2. HTTP와 HTTPS

HTTP와 HTTPS의 차이점으로는 보안성이 있습니다.

HTTP

HTTP 문제점의 문제점은 대체적으로 보안적인 문제가 있다는 것입니다. 특징 별로 살펴보겠습니다.

1. 평문 통신이기에 도청이 가능합니다

TCP/IP 구조의 통신은 전부 통신 경로 상에서 엿볼 수 있습니다. 패킷을 수집하는 것만으로 도청할 수 있습니다. 평문으로 통신을 할 경우 메시지의 의미를 파악할 수 있기 때문에 암호화하여 통신해야 합니다.

보완 방법
- 통신 자체를 암호화 SSL(Secure Socket Layer) or **TLS(Transport Layer Security)**라는 다른 프로토콜을 조합함으로써 HTTP 의 통신 내용을 암호화할 수 있습니다. SSL 을 조합한 HTTP 를 HTTPS(HTTP Secure) or HTTP over SSL이라고 부른다고 합니다.
- HTTP 메시지에 포함되는 콘텐츠만 암호화하는 것입니다. 암호화해서 전송하면 받은 측에서는 그 암호를 해독하여 출력하는 처리가 필요합니다.

2. 통신 상대를 확인하지 않기에 위장 가능합니다

HTTP 에 의한 통신에는 상대가 누구인지 확인하는 처리는 없습니다. IP 주소나 포트 등에서 그 웹 서버에 액세스 제한이 없는 경우, 리퀘스트가 오면 상대가 누구든지 리스폰스를 반환합니다.

따라서, 리퀘스트를 보낸 곳의 웹 서버가 원래 의도한 리스폰스를 보내야 하는 웹 서버인지를 확인할 수 없다는 문제점, 통신하고 있는 상대가 접근이 허가된 상대인지를 확인할 수 없다는 문제점, 의미없는 리퀘스트도 수신한다는 문제점 (Dos 공격)이 존재합니다.

보완 방법
- SSL로 상대를 확인할 수 있습니다. SSL은 상대를 확인하는 수단으로 증명서를 제공하고 있습니다. 증명서는 신뢰할 수 있는 제 3 자 기관에 의해 발행되는 것이기 때문에 서버나 클라이언트가 실재하는 사실을 증명합니다. 통신 상대가 내가 통신하고자 하는 서버임을 나타내고 이용자는 개인 정보 누설 등의 위험성이 줄어들게 됩니다. 한 가지 이점을 더 꼽자면 클라이언트는 이 증명서로 본인 확인을 하고 웹 사이트 인증에서도 이용할 수 있다고 합니다.

3. 정보의 정확성을 증명할 수 없어 변조가 가능합니다

서버 또는 클라이언트에서 수신한 내용이 송신측에서 보낸 내용과 일치한다라는 것을 보장할 수 없다는 것입니다. 리퀘스트 도중 무언가에 의해 변조되더라도 이 사실을 알 수 없습니다. 공격자가 도중에 리퀘스트나 리스폰스를 빼앗아 변조하는 공격을 **중간자 공격(Man-in-the-Middle)**이라고 합니다.

보완 방법
- MD5, SHA-1 등의 해시 값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이 존재하지만 확실히 확인할 수 있는 방법은 아니라고 합니다.
- 확실히 방지하기 위해선 HTTPS를 사용해야 합니다. SSL에는 인증이나 암호화 기능을 제공하고 있습니다.

HTTPS

HTTPS는 HTTP + SSL 라고 정리할 수 있습니다. HTTP에 암호화, 인증, 정보의 정확성 보호를 더한…!

HTTP 통신을 하는 소켓 부분을 SSL(Secure Socket Layer) or TLS(Transport Layer Security)라는 프로토콜로 대체하는 것입니다. HTTP 는 원래 TCP 와 직접 통신했지만, HTTPS 에서 HTTP 는 SSL 과 통신하고 SSL 이 TCP 와 통신 하게 됩니다.

SSL을 사용한 HTTPS 는 암호화와 증명서, 안전성 보호(= 정보 정확성)를 이용할 수 있게 된다.

HTTP - TCP

HTTP - SSL - TCP

HTTPS 의 SSL 에서는 공통키 암호화 방식과 공개키 암호화 방식을 혼합한 하이브리드 암호 시스템을 사용합니다.

모든 웹 페이지에서 HTTPS를 사용해도 될까요?

평문 통신에 비해서 암호화 통신은 CPU나 메모리 등 리소스를 더 많이 요구합니다. 통신할 때마다 암호화를 하면 추가적인 리소스를 소비하기 때문에 서버 한 대당 감당할 수 있는 리퀘스트의 수가 상대적으로 줄어들게 됩니다. 그래서 암호화 통신이 필요한 민감한 정보를 다룰 때만 HTTP 통신을 추천한다고 합니다.

하지만 최근에는 하드웨어의 발달로 인해 HTTPS를 사용하더라도 속도 저하가 거의 일어나지 않으며, 새로운 표준인 HTTP 2.0을 함께 이용한다면 오히려 HTTPS가 HTTP보다 더 빠르게 동작한다고 합니다.
따라서 웹은 과거의 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용하는 방식에서 -> 현재 모든 웹 페이지에서 HTTPS를 적용하는 방향으로 바뀌어가고 있다고 합니다

3. TCP 3 way handshake (연결 성립)

클라이언트는 서버에 접속을 요청하는 SYN(a) 패킷을 보냅니다.
서버는 클라이언트의 요청인 패킷을 받고, 클라이언트에게 요청을 수락한다는 ACK(a+1) 과 SYN(b) 가 설정된 패킷을 발송합니다.
클라이언트는 서버의 수락 응답인 패킷을 받고 ACK(b+1)를 서버로 보내면 연결리 성립됩니다!

(+ 연결 해제는 4 way handshake 방식으로 정리할 수 있습니다)

(+ ACK, SYN 은 코드 비트 1의 위치에 따라 결정되는 패킷(데이터의 형식화된 블록)입니다)

4. UDP 와 TCP

UDP

비연결형 프로토콜인 UDP(User Datagram Protocol, 사용자 데이터그램 프로토콜)는 IP 데이터그램을 캡슐화해 보내는 방법과 연결 설정을 하지 않고 보내는 방법을 제공합니다. 흐름제어, 오류제어 혹은 손상된 세그먼트에 대한 재전송을 하지 않습니다. 이것은 사용자의 프로세스의 몫이며, UDP는 포트를 사용하여 IP 프로토콜에 인터페이스를 제공합니다.

DNS는 UDP를 사용합니다. 어떤 호스트 네임의 IP 주소를 찾을 필요가 있는 프로그램은, DNS 서버로 호스트 네임을 포함한 UDP 패킷을 보냅니다. 이 서버는 호스트의 IP 주소를 포함한 UDP 패킷으로 응답합니다. 사전에 설정이 필요하지 않으며 그 후에 해제가 필요하지 않습니다.

TCP처럼 초기 설정에서 요구되는 프로토콜보다 적은 메시지가 요구됩니다.

TCP

인터넷 응용 분야들은 모두 신뢰성과 순차적 전달이 필요합니다. UDP로는 이를 만족시킬 수 없어 탄생한 프로토콜이 바로 TCP(Transmission Control Protocol, 전송제어 프로토콜)입니다.

신뢰성이 없는 인터넷을 통해 종단간에 신뢰성 있는 바이트 스트림을 전송하도록 설계되었습니다. TCP 는 송신자, 수신자 모두 소켓을 생성함으로써 이루어집니다. 위에서 설명한 3 way handshake를 통해 연결이 성립됩니다.

TCP는 전이중, 점대점 방식입니다. 전이중이란 전송이 양방향으로 동시에 일어날 수 있음을 의미하고, 점대점은 각 연결이 정확히 2개의 종단점을 가지고 있음을 의미합니다.

멀티캐스팅 혹은 브로드캐스팅은 지원하지 않습니다.

5. DNS Round Robin

Round Robin 이란 DNS 서버 구성 방식 중 하나입니다. 서버 도메인에 대한 IP 요청 쿼리 시 round-robin 방식으로 IP 를 반환합니다. 프로세스들 사이에 우선순위를 두지 않고, 순서대로 시간단위(Time Quantum/Slice)로 CPU를 할당하는 방식의 CPU 스케줄링 알고리즘입니다.

DNS Round Robin 방식의 문제점

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

균등하게 분산되지 않습니다. 모바일 사이트 등에서 문제가 될 수 있는데, 스마트폰의 접속은 캐리어 게이트웨이 라고 하는 프록시 서버를 경유 하는데요. 프록시 서버에서는 이름 변환 결과가 일정 시간 동안 캐싱되므로 같은 프록시 서버를 경유 하는 접속은 항상 같은 서버로 접속됩니다. PC 용 웹 브라우저도 DNS 질의 결과를 캐싱하기 때문에 균등하게 부하분산 되지 않습니다. DNS 레코드의 TTL 값을 짧게 설정함으로써 어느 정도 해소가 되지만, TTL 에 따라 캐시를 해제하는 것은 아니므로 반드시 주의가 필요하다고 합니다.

서버가 다운되도 확인 불가합니다. DNS 서버는 웹 서버의 부하나 접속 수 등의 상황에 따라 질의결과를 제어할 수 없습니다. 웹 서버의 부하가 높아서 응답이 느려지거나, 접속수가 꽉 차서 접속을 처리할 수 없는 상황인지 구분할 수 없습니다. 이때문에 유저들은 간혹 다운된 서버로 연결이 되기도 합니다.

Round Robin 방식을 기반으로 단점을 해소하는 DNS 스케줄링 알고리즘

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

6. 네트워크란 무엇인가?

컴퓨터 네트워크란 컴퓨터끼리 케이블이나 적외선, 전파 등 어떤 수단을 사용하여 연결해 다양한 데이터를 주고 받을 수 있는 상태로 되어 있는 것을 의미한다.
네트워크 종류에는 LAN, WAN, 인터넷이 있다.
- LAN (인트라넷) : 비교적 좁은 공간인 학교, 기업, 연구소 등의 컴퓨터 끼리 이어 구성한 네트워크를 말하고, 구리선을 짜넣은 LAN 케이블을 사용한다.
- WAN : 지리적으로 떨어져 있는 기기 끼리 연결한 비교적 대규모의 네트워크를 말하며, 광섬유 케이블이나, 회선을 이요한다.
- 인터넷 : LAN, WAN을 연결한 전세계 규모의 네트워크이다.