- referenced from JaeYeopHan
1️⃣ HTTP,GET,POST
1. Protocol과 HTTP란 무엇인가?
- Protocol : 컴퓨터 내부에서, 또는 컴퓨터 사이에서 데이터의 교환 방식을 정의하는 규칙 체계
- HTTP : 인터넷에서 Hyper Text(HTML)를 주고받을 수 있는 프로토콜, 즉 규격
쉽게 말해 우리가 네이버화면을 보여달라고 서버로 데이터(네이버 보여줘)를 전송하는 과정에서 HTTP가 사용된다.
2. 서버 요청
클라이언트에서 서버에 요청을 했을 때 보내는 데이터를 HTTP 패킷이라고 한다. 이 패킷은 헤더와 바디로 구성되어 있다. Header에는 보내는 사람의 주소, 받는 사람의 주소, 패킷의 생명 시간 (TTL, Time To Live) 등이 담겨 있고, Body에는 우리가 전하고자 하는 실제 내용이 들어 있다. 
2-1. GET
우선 GET 방식은 요청하는 데이터가 패킷의 Header 부분에 url 이 담겨서 전송된다. 아래의 그림에서 ?이전까지 요청하는 url이고 뒤에는 데이터가 "key - value"형태로 &로 구분되어 전송된다.
이러한 방식은 url 이라는 공간에 담겨가기 때문에 전송할 수 있는 데이터의 크기가 제한적이다. 또 보안이 필요한 데이터에 대해서는 데이터가 그대로 url 에 노출되므로 GET방식은 적절하지 않다.
또한 GET 방식의 요청은 브라우저에서 Caching 할 수 있다.
캐시 메모리는 실제 메모리와 CPU 사이에서 빠르게 데이터를 전달하기 위해 데이터를 저장해두는 좀 더 빠른 메모리이다.
네크워크에서 캐시는 로컬에 파일을 미리 다운 받아놓고, 그 내용을 보거나 웹서버에서 매번 로딩해야 하는 파일을 로딩해주고 응답을 주기도 한다. 하지만 기존에 caching 되었던 데이터가 응답될 가능성이 존재한다. 때문에 목적에 맞는 기술을 사용해야 하는 것이다.
2-2. POST
GET방식은 URL에 데이터를 붙여서 보내는 반면, POST방식은 URL에 붙여서 보내지 않고 패킷의 BODY에다가 데이터를 넣어서 보낸다.
따라서, 헤더필드중 BODY의 데이터를 설명하는 Content-Type이라는 헤더 필드가들어가고 어떤 데이터 타입인지 명시한다.
✅
정리하자면 GET은 서버에서 어떤 데이터를 가져와서 보여준다거나 하는 용도이지 서버의 값이나 상태 등을 변경하지 않는다. SELECT 적인 성향을 갖고 있다고 볼 수 있는 것이다. 반면에 POST 는 서버의 값이나 상태를 변경하기 위해서 또는 추가하기 위해서 사용된다.
referenced from link1, link2, link3, link4
2️⃣ TCP 3-way Handshake
해당 페이지의 4-1 TCP(Transmission Control Protocl) 참조
3️⃣ TCP와 UDP의 비교
UDP: UDP(User Datagram Protocol, 사용자 데이터그램 프로토콜)는 비연결형 프로토콜 이다. IP 데이터그램을 캡슐화하여 보내는 방법과 연결 설정을 하지 않고 보내는 방법을 제공한다. UDP는 흐름제어, 오류제어 또는 손상된 세그먼트의 수신에 대한 재전송을 하지 않는다. 이 모두가 사용자 프로세스의 몫이다. UDP가 행하는 것은 포트들을 사용하여 IP 프로토콜에 인터페이스를 제공하는 것이다.
종종 클라이언트는 서버로 짧은 요청을 보내고, 짧은 응답을 기대한다. 만약 요청 또는 응답이 손실된다면, 클라이언트는 time out 되고 다시 시도할 수 있으면 된다. 코드가 간단할 뿐만 아니라 TCP 처럼 초기설정(initial setup)에서 요구되는 프로토콜보다 적은 메시지가 요구된다.
UDP를 사용한 것들에는 DNS가 있다. 
어떤 호스트 네임의 IP 주소를 찾을 필요가 있는 프로그램은, DNS 서버로 호스트 네임을 포함한 UDP 패킷을 보낸다. 이 서버는 호스트의 IP 주소를 포함한 UDP 패킷으로 응답한다. 사전에 설정이 필요하지 않으며 그 후에 해제가 필요하지 않다.
TCP : TCP는 신뢰성이 없는 인터넷을 통해 신뢰성 있는 바이트 스트림을 전송하도록 설계되었다. TCP서비스는 송신자와 수신자가 모두 소켓이라고 부르는 종단점을 생성함으로써 이루어진다. 각 소켓은 호스트의 IP주소와 그 호스트에 국한된 16비트로 구성된 포트라고 불리는 소켓번호를 갖는다. TCP 서비스를 하기 위해서는 송신측 소켓과 수신측 소켓이 연결되어 있어야 한다.
모든 TCP서비스는 전이중(full-duplex), 점대점(point-to-point)방식이다. 전이중이란 전송이 양방향으로 동시에 일어날 수 있음을 의미하며, 점대점이란 각 연결이 정확히 2개의 종단점을 가지고 있음을 의미한다. TCP는 멀티태스킹이나 브로드캐스팅을 지원하지 않는다.
4️⃣ HTTP와 HTTPS
1. HTTP의 문제점
❶ HTTP는 평문이기 때문에 도청이 가능하다
❷ 통신상대를 확인하기 않기 때문에 위장이 가능하다
❸ 완전성을 증명할 수 없기에 변조가 가능하다
단 위 세 가지는 다른 암호화되지 않은 프로토콜에도 공통되는 문제점이다.
❶ TCP/IP는 도청 가능한 네트워크이다
TCP/IP 구조의 통신은 전부 통신 경로 상에서 엿볼 수 있다. 패킷을 수집하는 것만으로 도청할 수 있다. 평문으로 통신할 경우 메세지의 의미를 파악할 수 있기 때문에 암호화하여 통신해야 한다.
보완방법
- 통신 자체를 암호화 SSL(Secure Socket Layer) or TLS(Transport Layer Security)라는 프로토콜을 조합함으로써 TCP의 통신 내용을 암호화할 수 있다. SSL을 조합한 HTTP를 HTTPS(HTTP Secure) or HTTP over SSL이라고 부른다.
- 콘테츠만 암호화, 말 그대로 HTTP를 사용해서 운반하는 내용인, HTTP 메세지에 포함되는 콘텐츠만 암호화하는 것이다. 암호화해서 전송하면 받은 측에서는 그 암호를 해독하는 처리가 필요하다.
❷ 통신상대를 확인하기 않기 때문에 위장이 가능하다
HTTP에 의한 통신에는 상대가 누구인지 확인하는 처리가 없기 때문에 누구든지 리퀘스트를 보낼 수 있다. IP주소나 포트 등그 웹 서버에 엑세스 제한이 없는 경우, 리퀘스트가 오면 상대가 누구든지 무언가의 response를 반환한다. 이러한 특징은 여러 문제점을 유발한다.
문제점
- request를 보낸 곳의 웹 서버가 원래 의도한 response를 보내야 하는 웹 서버인지를 확인할 수 없다.
- response를 반환한 곳의 클라이언트가 원래 의도한 request를 보낸 클라이언트인지 확인할 수 없다.
- 통신하고 있는 상대가 접근이 허가된 상대인지를 확인할 수 없다.
- 의미없는 request를 수신하기도 한다. -> DoS 공격을 방지할 수 없다.
보완방법
- 위 통신암호화 방법으로 언급된 SSL로 상대를 확인할 수 있다. SSL은 상대를 확인하는 수단으로 증명서를 제공하고 있다. 증명서는 신뢰할 수 있는 제 3자 기관에 의해 발행된 것이기 때문에 서버나 클라이언트는 실재하는 사실을 증명한다. 이 증명서를 이용함으로써 통닛 상대가 내가 통신하고자 하는 서버임을 나타내고 이용자는 개인 정보 누설 등의 위험성을 줄어들게 된다. 한 가지 이점을 더 꼽자면, 클라이언트는 이 증명서로 본인 확인을 하고 웹 사이트 인증에서도 사용할 수 있다.
❸ 완전성을 증명할 수 없기 때문에 변조가 가능하다.
여기서 완전성이란 정보의 정확성을 의미한다. 서버 또는 클라이언트에서 수신한 내용이 송신측에서 보낸 내용과 일치한다는 것을 보장할 수 없는 것이다. request나 response가 발신된 후에 상대가 수신하는 사이에 누군가에 의해 변조되더라도 이 사실을 알 수 없다. 이와 같이 공격자가 도중에 request나 response를 빼앗아 변조하는 공격을 중간자 공격(Man-in-the-Middle)이라고 부른다
보완방법
MD5, SHA-1 등의 해시 값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이 있지만 확실히 확인할 수 있는 것은 아니다. 확실히 방지하기에는 HTTPS를 사용해야 한다. SSL에는 인증이나 암호화, 그리고 다이제스트 기능을 제공하고 있다.
2. HTTPS
HTTP는 SSL의 껍질을 덮어쓴 HTTP라고 할 수 있다. 즉, HTTPS는 새로운 어플리케이션 계층의 프로토콜이 아니라는 것이다. HTTP 통신하는 소켓 부분을 SSL(Secure Socket Layer) or TLS(Transport Layer Security)라는 프로토콜로 대체하는 것 뿐이다. HTTP는 원래 TCP와 직접 통신했지만, HTTPS에서 HTTP는 SSL과 통신하고 SSL이 TCP와 통신하게 된다. SSL을 사용한 HTTPS는 암호화와 증명서, 안전성 보호를 이용할 수 있게 된다.
HTTPS의 SSL에서는 공통키 암호화 방식과 공개키 암호화 방식을 혼합한 하이브리드 암호 시스템을 사용한다. 공통키를 공개키 암호화 방식으로 교환한 다음에 다읍부터의 통신은 공통키 암호를 사용하는 방식이다.
2-1. 모든 웹 페이지에서 HTTP를 사용해도 될까?
평문 통신에 비해서 암호화 통신은 CPU나 메모리 등 리소스를 더 많이 요구한다. 통신할 때마다 암호화를 하면 추가적인 리소스를 소비하기 때문에 서버 한 대당 처리할 수 있는 리퀘스트의 수가 상대적으로 줄어들게 된다.
하지만 최근애는 하드웨어의 발달로 인해 HTTPS를 사용하더라도 속도 저하가 거의 일어나지 않으며, 새로운 표준의 HTTP 2.0을 함께 이용한다면 오히려 HTTPS가 HTTP보다 더 빠르게 동작한다. 따라서 웹은 과거에 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용했지만 현재 모든 웹 페이지에서 HTTPS르 적용하는 방향으로 바뀌어가고 있다.
5️⃣ DNS round robin 방식
1. DNS란?
- Domain Name System의 약자로 www.xxx.com과 같이 사람이 읽을 수 있는 이름을 192.0.0.1과 같은 숫자 IP주소로 변환하여 컴퓨터가 서로 통신할 수 있도록 도와주는 서버이다.
- DNS 시스템은 이름을 숫자로 매핑하여 전화번호 부와 같은 역활을 한다.
- DNS서버는 이름에 대한 요청을 IP주소로 변환하여, 최종 사용자가 도메인 이름을 웹 브러우저에 입력할 때 해당 사용자를 어떤 서버로 연결할 것인지를 제어한다.
DNS Query : DNS 서버에서 domain name을 이용하여 IP를 받아온다
IP Communication : IP를 받아온 유저는 request 메세지 발송을 통하여 정상적으로 네트워크 통신을 실시한다.
2. DNS 동작원리 
❶ 사용자가 www.naver.com을 브라우저에 입력한다.
❷ local DNS에게 IP주소를 질의하여 캐시된 것이 없으면 다른 DNS 서버에 전달(Root DNS)
❸ ROOT로부터 com도메인을 관리하는 TLD이름 서버 정보 전달 받는다
❹ COM DNS로 질의한다.
❺ naver.com DNS 정보를 전달 받는다
❻ www.naver.com 호스트네임에 대한 IP주소를 질의한다
❼ IP 정보를 전달받는다.
❽ local DNS는 www.naver.com에 대한 IP주소를 캐싱하고 IP주소 정보를 전달한다.
<ROOT -> COM -> xxx.com 서버를 차례대로 질의해서 답을 찾는 과정을 Recursive Query라고 한다.>
3. DNS Round Robin
round robind은 DNS 서버 구성 방식 중 하나이다. 
- 웹 서비스를 담당하는 여러 대의 웹 서버는 자신의 공인 IP를 각각 가지고 있다.
- 사이트 접속을 위해 사용자가 해당 도메인 주소를 브러우저에 입력하면 DNS는 도메인 정보를 조회하는데 이때 IP주소를 여러 대의 서버 IP리스트 중에서 라운드 로빈 형태로 랜점하게 하나 혹은 여러개를 선택하여 사용자에서 알려준다.
- 결과적으로 웹 사이트에 접속하는 다수의 사용자는 실제로는 복수의 웹 서버에 나뉘어 접속하도록 되어 자연스럽게 서버의 부하가 분산되는 방식이다.
결과적으로 라운드 로빈 DNS는 여러개의 IP주소를 결과로 돌려준다. 사용자의 OS 어플리케이션에 따라 다르게 동작된다. 여러갸의 IP중 제일 먼저 조회된 IP를 선택, 무작위로 IP를 선택한다. 또는 선택 IP접속이 안되면 그 다음 조회된 IP로 접속하도록 호직을 추가할 수 있다.
4. DNS Round Robin 방식의 문제점
❶ 서버의 수만큼 공인 IP주소가 필요함.
부하 분산을 위해 서버의 대수를 늘리기 위해서는 그 만큼의 공인 IP가 필요하다.
❷ 균등하게 분산되지 않음.
모바일 사이트 등에서 문제가 될 수 있는데, 스마트폰의 접속은 캐리어 게이트웨어라고 하는 프록시 서버를 경유한다. 프록시 서버에서는 이름변환 결과가 일정 시간동안 캐싱되므로 같은 프록시 서버를 경유하는 접속은 항상 같은 서버로 접속된다. 또한 PC용 웹 브라우저도 DNS 질의 결과를 캐싱하기 때문에 균등하게 부하준산 되지 않는다. DNS 레코드의 TTL값을 짧게 설정함으로써 어느 정도 해소가 되지만, TTL에 따라 캐시를 해제하는 것은 아니므로 반드시 주의가 필요하다.
❸ 서버가 다운돼도 확인이 불가함.
DNS 서버는 웹 서버의 부하나 접속 수 등의 상황에 따라 질의결과를 제어할 수 없다. 웹 서버의 부하가 높아서 응답이 느려지거다 접속 수가 꽉 차서 접속을 처리할 수 없는 상환인 지를 젼혀 감지할 수 없기 때문에 어떤 원인으로 다운되더라도 이를 검출하지 못하고 유저들에게 제공한다. 이때문에 유저들은 간혹 다운된 서버로 연결되기도 한다. DNS 라운드 로빈은 어디까지나 부하 분산을 위한 방법이지 다중화 방법은 아니므로 다른 S/W와 조합해서 관리할 필요가 있다.
해결법
❶ 가중치 편성 방식 (Weighted round robin)
각각의 웹 서버에 가중치를 가미해서 분산 비율을 변경한다. 물론 가중치가 큰 서버일수록 빈번하게 선택되므로, 처리능력이 높은 서버의 가중티를 높게 설정하는 것이 좋다.
❷ Least connection
접속 클라이언트 수가 가장 적은 서버를 선택한다. 로드밸런스에서 실시간으로 connection 수를 관리하거나 각 서버에서 주기적으로 알려주는 것이 필요하다. 
6️⃣ 웹 통신의 큰 흐름
우리가 chrome을 실행시켜 주소창에 특정 URL을 입력시키면 어떤 일이 일어나는가?
A. in 브라우저
❶ url에 입력된 값을 브라우저 내부에서 결정된 규칙에 따라 그 의미를 조사한다.
❷ 조사된 의미에 따라 HTTP Request 메세지를 만든다.
❸ 만들어진 메세지를 웹 서버로 전송한다.
이때 만들어진 메세지 전송은 브라우저가 직접하는 것이 아니다. 브라우저는 메세지를 네트워크에 송출하는 기능이 없으므로 OS에 의뢰하여 메세지를 전달한다. 우리가 택배를 보낼 때 직접 보내는게 아니라, 이미 서비스가 이루어지고 있는 택배 시스템(택배회사)를 이용하여 보내는 것과 같은 이치이다. 단, OS에 송신을 의뢰할 때는 도메인명이 아니라 IP주소로 받을 상대를 지정해야 하는데, 이 과정에서 DNS서버를 조회한다. = DNS -> OS ->송출 순
B. in 프로토콜 스택, LAN 어댑터
- 프로토콜 스택 : 계층화된 구조로 모여 있는 프로토콜의 집합
- 랜 자체는 물리 계층에서 작동하고, LAN 어댑터(또는 랜카드라 불림)은 데이터 링크에서 사용된다.
❶ 프로토콜 스택(운영체제에 내장된 네트워크 제어용 소프트웨어)이 브라우저로부터 메세지를 받는다.
❷ 브라우저로부터 받은 메세지를 패킷 속에 저장한다.
❸ 그리고 수신처 주소 등의 제어정보를 덧붙인다.
❹ 그런 다음, 패킷을 LAN 어댑터에 넘긴다.
❺ LAN 어댑터는 다음 Hop의 MAC주소를 붙인 프레임을 전기신호로 변환시킨다.
❻ 신호를 LAN 케이블에 송출시킨다.
프로토콜 스택은 통신 중 오류가 발생했을 때, 이 제어 정보를 사용하여 고쳐 보내거나, 각종 상황을 조절하는 등 다양한 역활을 하게된다. 네트워크 세계에서는 비서가 있어서 우리가 비서에게 물건을 건네주면, 받는 사람의 주소와 각종 유의사항을 써준다! 여기서는 프로토콜 스택이 비서의 역활을 한다고 볼 수 있다.
C. in 허브, 스위치, 라우터
❶ 클라이언트 PC는 가정이나 회사의 LAN을 경유하거나 단독으로 인터넷에 접속할 수 있다.
❷ LAN 어댑터가 송신한 패킷은 스위칭 허브 등을 경유하여 인터넷 접속용 라우터에 도착한다.
❸ 라우터의 앞부분은 이미 인터넷이므로 여기서부터 앞부분은 통신사가 패킷을 상대에게 운반하게 된다.
D. in 액세스 회선, 프로바이터
E. in 방화벽, 캐시서버
❶ 패킷은 인터넷 핵심부를 통과하여 웹 서버측의 LAN에 도착한다.
❷ 기다리고 있던 방화벽이 도착한 패킷을 검사한다
❸ 패킷이 웹 서버까지 가야하는지 가지 않아도 되는지를 판단하는 캐시서버가 존재한다.
F. in 웹 서버
❶ 패킷이 물리적인 웹 서버에 도착하면 웹 서버의 프로토콜 스택은 패킷을 추출하여 메세지를 복원하고 웹 서버 어플리케이션에 넘긴다.
❷ 메세지를 받은 웹 서버 어플리케이션은 리퀘스트 메세지의 의미를 읽고, 여기에 쓰여있는 지시에 따라 데이터를 응답 메세지에 넣어 클라이언트에 회송한다.
