network 개요

HTTP의 GET과 POST 비교

GET

• 데이터가 HTTP Request Message의 헤더부분의 url에 담겨서 전송됨. url의 끝에 ? 뒤에 데이터를 붙여 요청.
• 데이터의 크기가 제한적임.
• 데이터가 url에 노출되므로 보안에 약함

POST

• 데이터가 HTTP Requst Message의 바디부분에 담김
• 데이터 크기가 커도 됨. GET 방식보다 보안적임.

어디에 무엇을 적용할까?

• 서버에서 데이터를 가져와서 보여줄때
  • GET 방식이 적합함
• 서버의 값이나 상태 등을 변경할때
  • POST 방식이 적합함.
• Caching이 필요할때
  • GET 방식이 적합함. GET 방식의 요청은 브라우저에서 Caching 할 수 있기때문에.
• Caching이 이뤄지면 안될때
  • POST 방식이 적합

TCP 3-way Handshake

SYN 패킷, ACK 패킷

SYN : Synchronize sequence number

ACK : acknowledgement

TCP 헤더에는 Code bit(flag bit)가 존재함. 이부분을 총 6비트로 이루어져있고, 각 bit는 Urg-ACK-PSH-RST-SYN-FIN 순서로 의미를 가지고 있다. 해당 위치의 비트로 패킷의 의미를 나타내는 것이다.

연결 성립

1. 클라이언트가 서버에 접속을 요청하는 SYN(a) 패킷을 보냄
2. 서버는 SYN(a)를 받고, 요청을 수락한다는 ACK(a+1)와 SYN(b)이 설정된 패킷을 발송함
3. 클라이언트는 ACK(a+1)와 SYN(b) 패킷을 받고, ACK(b+1)를 서버로 보내면 연결이 성립됨.

연결 해제

1. 클라이언트가 연결을 종료하겠다는 FIN 플래그를 전송함
2. 서버는 FIN을 받고, 알았다는 ACK 를 보냄.
3. 서버는 남은 데이터를 모두 보내고, 다 보냈으면 FIN 플래그를 클라이언트로 전송함
4. 클라이언트는 FIN 플래그를 받고, 알았다는 ACK를 보냄
5. 서버는 ACK를 받고 소켓을 close함.
6. 클라이언트는 아직 서버로부터 받지 못한 데이터가 있을 수도 있으니, 일정시간동알 세션을 남겨놓고 잉여패킷을 기다림

3way인 이유

TCP 연결은 양방향성이므로, 서로의 연결이 제대로 됐는지 확인해야한다.

따라서 1. 클라이언트가 서버로 요청함. 2. 서버가 확인하고 클라이언트로 요청함. 3. 클라이언트가 확인함.

이렇게 3 과정이 필요하다.

why randomized Sequence number

처음 클라이언트에서 SYN 패킷을 보낼때 Sequence number에는 랜덤한 숫자가 담겨짐. 초기 sequence number를 ISN이라고 함.

이때 랜덤하게 초기 ISN을 설정하는 이유는 클라이언트와 서버가 연결을 맺을때 사용하는 포트는 유한 범위 내에서 사용하고 시간이 지남에 따라 재사용되기때문이다. 따라서 두 통신 호스트가 과거에 사용된 포트번호 쌍을 사용하는 가능성이 존재한다. 서버측은 패킷의 SYN을 보고 패킷을 구분하게 되는데 난수가 아닌 순차적은 number가 전송된다면 이전의 connection으로부터 오는 패킷으로 인식할 수 있다. 이러한 문제가 발생할 가능성을 줄이기 위해 난수로 ISN을 설정하는 것이다.

TCP와 UDP의 비교

UDP(User Datagram Protocol)

• 비연결형 프로토콜.
• IP 데이터그램을 캡슐화하여 보내는 방법과 연결설정을 하지 않고 보내는 방법을 제공함.

• 흐름제어, 오류제어, 손상된 세그먼트 재전송을 하지 않음. 포트를 사용하여 IP 프로토콜에 인터페이스를 제공하는 작업만 함. 클라이언트는 요청/응답이 손실되면 timeout되고 다시 시도하면 된다.

• 코드가 간단하며 TCP 처럼 초기설정이 요구되지 않아 적은 메시지로 통신이 가능하다.
• 사용 하는 곳 : DNS
  • 클라이언트는 호스트네임이 포함된 UDP 패킷을 DNS로 보내고, DNS는 해당하는 IP주소를 포함한 UDP 패킷을 응답함.
  • 사전에 설정이 필요없고, 이후 해제도 필요없다.

TCP(Transmission Control Protocol)

• 연결형 프로토콜
• 신뢰성과 순차적인 전달을 보장함.
• 송신자와 수진자 모두가 소켓이라고 부르는 종단점을 생성하여 연결된다.
• TCP에서의 연결은 3-way-handshake를 통해 이루어진다.
• TCP 연결 종류
  • 전이중(full-duplex) : 전송이 양방향으로 동시에 일어날 수 있음을 의미
  • 점대점(point to point) : 각 연결이 정확히 2개의 종단점을 가지고 있음을 의미.
• 멀티 캐스팅이나 브로드캐스팅 지원은 안함.

HTTP와 HTTPS

HTTP의 문제점

• HTTP는 평문 통신(암호화안된 통신)이기 때문에 도청이 가능하다.
• 통신 상대를 확인하지 않기때문에 위장이 가능하다.
• 완전성을 증명할 수 없기 때문에 변조가 가능하다.

TCP/IP 는 도청가능한 네트워크이다

TCP/IP 구조의 통신은 통신경로 상에서 엿볼 수 있다. 중간에 패킷을 수집하면 된다. 이때 HTTP는 평문통신이기에 패킷이 유출되면 메시지의 의미를 파악할 수 있고, 이때 도청이 이루어진다.

보완

1. 통신 자체를 암호화한다.
   • SSL(Secure Socket Layer)나 TLS(Transport Layer Security)라는 다른 프로토콜을 조합함으로써 HTTP 통신 자체를 암호화할 수 있다. 여기서 특히 SSL을 조합한 HTTP를 HTTPS 라고 부른다.
2. 콘텐츠를 암호화
   • HTTP 메세지에 포함된 컨텐츠만 암호화하는 방법
   • 서로 간의 해독방법이 필요하다.

통신 상대를 확인하지 않기때문에 위장이 가능함

HTTP에 의한 통신에는 상대가 누구인지 확인하는 처리가 없기때문에, 누구든지 요청을 보낼 수 있다. 따라서 IP주소나 포트번호의 제한이 없는한 요청이 오면 서버는 무엇이든 응답을 반환한다. 여기서 문제가 발생한다.

1. 요청을 보낸 곳의 웹서버가 원래 의도한 응답을 보내야하는 웹서버인지 확인할 수 없음
2. 응답을 반환한 곳의 클라이언트가 원래 의도한 요청을 보낸 클라이언트인지 확인할 수 없음
3. 통신하고 있는 상대가 접근이 허가 된 상대인지 확인 불가능
4. 어디에서 누가 요청했는지 확인할 수 없음
5. 의밍벗는 요청도 수신함 -> DDos 공격에 취약

보완

SSL로 해결할 수 있다. SSL은 상대를 확인하는 수단으로 증명서를 제공하고 있다. 증명서는 신뢰가능한 제 3자가 발행하는 것이기에 서버나 클라이언트가 실재하는 사실을 증명한다. 이 증명서를 이용함으로써 통신 상대가 내가 통신하고자하는 서버임을 나타내고, 이용자는 개인정보 누설의 위험성이 줄어든다. 또 클라이언트는 이 증명서로 본인확인을 하고, 웹사이트 인증에서도 이용할 수 있다.

완전성을 증명할 수 없기 때문에 변조가 가능하다

송신측에서 보낸 내용과 수신측에서 받은 내용이 일치하다는 것을 보장할 수 없다. 따라서 누가 중간에서 변조하더라도 이사실을 알 수 없다. 이와 같이 중간에서 요청/응답을 빼앗아 변조하는 것을 중간자 공격이라고 한다.

보완

MD5, SHA-1 등의 해시 값을 확인하는 방법과 디지털 서명을 확인하는 방법이 존재하지만 확실하지는 않음

SSL 에는 인증이나 암호화, 다이제스트 기능이 제공되기에, 확실히 방지된다.

HTTPS

HTTP에 SSL을 더한 것으로, HTTP 통신하는 소켓부분을 SSL이나 TLS라는 프로토콜로 대체하는 것뿐이다. HTTP는 원래 TCP와 직접 통신했지만, HTTPS 에는 SSL이 TCP와 통신하게 된다.

HTTPS는 SSL을 사용하여 암호화와 증명서, 안전성 보호를 이용할 수 있게 된다.

SSL에서는 공통키 암호화 방식과 공개키 암호화 방식을 혼합한 암호 시스템을 사용한다. 공통키를 공개키 암호화 방식으로 교환한 다음에 다음부터는 공통키 암호를 사용하는 방식이다.

모든 웹 사이트에서 HTTPS를 사용해야할까?

HTTPS 통신은 암호화 통신이기에 HTTP보다 많은 리소스를 요구한다. 하지만 최근 하드웨어의 발달로 속도저하가 거의 일어나지 않으며, HTTP 2.0을 사용한다면 오히려 HTTPS가 HTTP보다 빠르게 동작한다.

따라서 최근에는 모든 웹페이지에서 HTTPS를 적용하는 방향으로 바뀌어가고 있다.

DNS round robin 방식

DNS Round Robin

• DNS에서 레코드 정보를 조회하는 시점에서 트래픽을 분산하는 방법
• 부하 분산을 위한 서버를 여러대 두고, 각 서버마다의 공인 IP 주소를 가진다. 그리고 사용자가 도메인으로 접속하면 DNS에서는 하나의 공인 IP를 반환하여 분산하는 방법이다.
• 라운드로빈 DNS를 통해 반환된 공인 IP 리스트를 처리하는 표준 절차가 정해져있지 않기 때문에 여러 단점이 존재한다.

DNS Round Robin 방식의 문제점

1. 서버의 수만큼 공인 IP 주소가 필요함

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

2. 균등하게 분산되지 않음

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

3. 서버가 다운되도 확인불가

   • DNS 서버는 웹 서버의 부하나 접속 수 등의 상황에 따라 질의결과를 제어할 수 없다. 따라서 서버가 다운된 상황에서도 이를 검출하지 못하고 유저에게 제공한다.
   • 따라서 무중단 서비스에서는 라운드로빈 DNS를 사용하면 안된다.

따라서 DNS Round Robin은 부하분산을 위한 방법이지 다중화 방법은 아니므로 다른 방법과 조합해서 관리할 필요가 있다.

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

1. Weighted Round Robin(WRR)
   • 각각의 웹 서버에 가중치를 가미해서 분산 비율을 변경한다.
   • 가중치가 큰 서버일수록 빈번하게 선택되므로 처리능력이 높은 서버는 가중치를 높게 설정하는 것이 좋다.
2. Least Connection
   • 접속 클라이언트 수가 가장 적은 서버를 선택한다.
   • 로드밸런서에서 실시간으로 connection 수를 관리하거나 각 서버에서 주기적으로 알려주는 것이 필요하다.

웹 통신의 큰 흐름

사용자가 브라우저에서 특정 URL를 입력했을때 일어나는 일들.

In 브라우저

1. url에 입력된 값을 브라우저 내부에서 결정된 규칙에 따라 그 의미를 조사한다.
2. 조사된 의미에 따라 HTTP Request 메시지를 만든다.
3. 만들어진 메시지를 웹 서버로 전송한다.
   • 이때 브라우저는 메시지를 네트워크에 송출하는 기능이 없으므로, OS에 의뢰하여 메시지를 전달한다.
   • 단, OS에 송신을 의뢰할 때는 도메인명이 아니라, ip주소로 메시지를 받을 대상을 지정해야하는데 이때 DNS 서버를 조회해야한다.

In 프로토콜 스택, LAN 어댑터

1. 프로토콜 스택(OS에 내장된 네트워크 제어용 소프트웨어)이 브라우저로부터 메시지를 받는다.
2. 브라우저로부터 받은 메시지를 패킷 속에 저장한다.
3. 패킷에 수신처 주소 등의 제어정보를 덧붙인다.
4. 패킷을 LAN 어댑터에 넘긴다.
5. LAN 어댑터는 다음 Hop의 MAC 주소를 붙인 프레임을 전기신호로 변환시킨다.
6. 신호를 LAN 케이블로 송출시킨다.

프로토콜 스택은 통신 중 오류가 발생했을때, 이 제어정보를 사용하여 고쳐보내거나, 각종 상황을 조절하는 등 다양한 역할을 하게 된다.

In 허브, 스위치, 라우터

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

In 액세스 회선, 프로바이더

1. 패킷은 인터넷 입구에 있는 액세스 회선(통신회선)에 의해 POP(Point of Presence, 통신사용 라우터)까지 운반된다.
2. POP을 거쳐 인터넷의 핵심부로 들어가게 된다.
3. 수많은 고속 라우터 사이로 패킷이 목적지를 향해 흘러가게 된다.

In 방화벽, 캐시서버

1. 패킷은 인터넷 핵심부를 통과하여 웹 서버측의 LAN에 도착한다.
2. 방화벽이 도착한 패킷을 검사한다.
3. 패킷이 웹 서버까지 가야하는지 가지 않아도 되는지를 판단하는 캐시서버가 존재한다.
   • 서버까지 가지 않아도 될 경우, 자기 내부에 있는 캐싱 된 데이터를 바로 보낸다.

In 웹서버

1. 패킷이 물리적인 웹 서버에 도착하면, 웹 서버의 프로토콜 스택은 패킷을 추출하여 메시지를 복원하고, 웹 서버 애플리케이션에 넘긴다.
2. 메시지를 받은 웹 서버 어플리케이션은 요청 메시지에 따른 데이터를 응답 메시지에 넣어 클라이언트로 회송한다.
3. 왔던 방식대로 클라이언트로 돌아간다.

출처

https://github.com/JaeYeopHan/Interview_Question_for_Beginner/tree/master/Network

https://asfirstalways.tistory.com/356

https://judo0179.tistory.com/127