다짐하자/출근 준비

22.01.26 - [ 네트워크 ] Network

giggs 2023. 1. 27. 08:41

 

 

-- INDEX --

 

 

1. HTTP의 GET과 POST 2. 3 way handshake 3. TCP와 UDP의 비교
서버에 무엇인가를
요청할 때 사용하는 방식		 SYN패킷과 ACK 비연결형 프로토콜
? 뒤에 데이터가 붙음
request Body에 데이터 담음		 FIN 플래그와 ACK 종단간에 신뢰성 있는
바이트 스트림 전송

 

 

4. TCP 흐름제어 / 혼잡제어 5. HTTP 와 HTTPS 6. 웹 통신의 큰 흐름
송신측/수신측
데이터 처리 속도 차이를 해결		 평문 브라우저 ~~~
~ LAN 어댑터 ~
~ 허브, 스위치, 라우터 ~
~~~ 웹 서버
송신측의
데이터 전달과
데이터 처리 속도 차이 해결		 SSL암호화

 

 

 

 

 

 

 

 

1. HTTP의 GET과 POST 

  • 둘 다 HTTP 프로토콜을 이용해서 서버에 무엇인가를 요청할 때 사용하는 방식이다.
  • 하지만 둘의 특징을 제대로 이해하여 기술의 목적에 맞게 알맞은 용도에 사용해야 한다.

 

 

1-1 : GET

  • 우선 GET 방식은 요청하는 데이터가 HTTP Request Message의 Header 부분에 url 이 담겨서 전송된다.
  • 때문에 url 상에 ? 뒤에 데이터가 붙어 request 를 보내게 되는 것이다.
  • 이러한 방식은 url 이라는 공간에 담겨가기 때문에 전송할 수 있는 데이터의 크기가 제한적이다.
  • 또 보안이 필요한 데이터에 대해서는 데이터가 그대로 url 에 노출되므로 GET방식은 적절하지 않다. (ex. password)

 

 

 

1-2 : POST

  • POST 방식의 request 는 HTTP Request Message의 Body 부분에 데이터가 담겨서 전송된다.
  • 때문에 바이너리 데이터를 요청하는 경우 POST 방식으로 보내야 하는 것처럼 데이터 크기가 GET 방식보다 크고 보안면에서 낫다.(하지만 보안적인 측면에서는 암호화를 하지 않는 이상 고만고만하다.)
  • 그렇다면 이러한 특성을 이해한 뒤에는 어디에 적용되는지를 알아봐야 그 차이를 극명하게 이해할 수 있다. 
  • 우선 GET 은 가져오는 것이다. 서버에서 어떤 데이터를 가져와서 보여준다거나 하는 용도이지 서버의 값이나 상태 등을 변경하지 않는다. SELECT 적인 성향을 갖고 있다고 볼 수 있는 것이다.
  • 반면에 POST 는 서버의 값이나 상태를 변경하기 위해서 또는 추가하기 위해서 사용된다.
  • 부수적인 차이점을 좀 더 살펴보자면 GET 방식의 요청은 브라우저에서 Caching 할 수 있다.
  • 때문에 POST 방식으로 요청해야 할 것을 보내는 데이터의 크기가 작고 보안적인 문제가 없다는 이유로 GET 방식으로 요청한다면 기존에 caching 되었던 데이터가 응답될 가능성이 존재한다. 때문에 목적에 맞는 기술을 사용해야 하는 것이다.

 

 

 

 

 

 

2. [ TCP ] 3 way handshake & 4 way handshake

 

 

2-1 : 3 way handshake - 연결 성립

  • TCP는 정확한 전송을 보장해야 한다.
  • 따라서 통신하기에 앞서, 논리적인 접속을 성립하기 위해 3 way handshake 과정을 진행한다.

 

 

 

 

  1. 클라이언트가 서버에게 SYN 패킷을 보냄 (sequence : x)
  2. 서버가 SYN(x)을 받고, 클라이언트로 받았다는 신호인 ACK와 SYN 패킷을 보냄 (sequence : y, ACK : x + 1)
  3. 클라이언트는 서버의 응답은 ACK(x+1)와 SYN(y) 패킷을 받고, ACK(y+1)를 서버로 보냄
  • 이렇게 3번의 통신이 완료되면 연결이 성립된다. (3번이라 3 way handshake인 것)

 

 

 

2-2 : 4 way handshake - 연결 해제

  • 연결 성립 후, 모든 통신이 끝났다면 해제해야 한다.

 

 

 

 

  1. 클라이언트는 서버에게 연결을 종료한다는 FIN 플래그를 보낸다.
  2. 서버는 FIN을 받고, 확인했다는 ACK를 클라이언트에게 보낸다. (이때 모든 데이터를 보내기 위해 CLOSE_WAIT 상태가 된다)
  3. 데이터를 모두 보냈다면, 연결이 종료되었다는 FIN 플래그를 클라이언트에게 보낸다.
  4. 클라이언트는 FIN을 받고, 확인했다는 ACK를 서버에게 보낸다. (아직 서버로부터 받지 못한 데이터가 있을 수 있으므로 TIME_WAIT을 통해 기다린다.)
  • 서버는 ACK를 받은 이후 소켓을 닫는다 (Closed)
  • TIME_WAIT 시간이 끝나면 클라이언트도 닫는다 (Closed)
  • 이렇게 4번의 통신이 완료되면 연결이 해제된다.

 

 

 

 

 

3. TCP와 UDP의 비교

 

3-1 : UDP

  • UDP(User Datagram Protocol, 사용자 데이터그램 프로토콜)는 비연결형 프로토콜 이다.
  • IP 데이터그램을 캡슐화하여 보내는 방법과 연결 설정을 하지 않고 보내는 방법을 제공한다. 
  • UDP는 흐름제어, 오류제어 또는 손상된 세그먼트의 수신에 대한 재전송을 하지 않는다. 이 모두가 사용자 프로세스의 몫이다. 
  • UDP가 행하는 것은 포트들을 사용하여 IP 프로토콜에 인터페이스를 제공하는 것이다.
  • 종종 클라이언트는 서버로 짧은 요청을 보내고, 짧은 응답을 기대한다.
  • 만약 요청 또는 응답이 손실된다면, 클라이언트는 time out 되고 다시 시도할 수 있으면 된다.
  • 코드가 간단할 뿐만 아니라 TCP 처럼 초기설정(initial setup)에서 요구되는 프로토콜보다 적은 메시지가 요구된다.
  • UDP를 사용한 것들에는 DNS가 있다. 어떤 호스트 네임의 IP 주소를 찾을 필요가 있는 프로그램은, DNS 서버로 호스트 네임을 포함한 UDP 패킷을 보낸다. 이 서버는 호스트의 IP 주소를 포함한 UDP 패킷으로 응답한다.
  • 사전에 설정이 필요하지 않으며 그 후에 해제가 필요하지 않다.
  • UDP는 왜 사용할까?
  • UDP의 결정적인 장점은 데이터의 신속성이다. 데이터의 처리가 TCP보다 빠르다.
  • 주로 실시간 방송과 온라인 게임에서 사용된다. 네트워크 환경이 안 좋을때, 끊기는 현상을 생각하면 된다.

 

 

 

3-2 : TCP

  • 대부분의 인터넷 응용 분야들은 신뢰성과 순차적인 전달을 필요로 한다.
  • UDP 로는 이를 만족시킬 수 없으므로 다른 프로토콜이 필요하여 탄생한 것이 TCP이다. 
  • TCP(Transmission Control Protocol, 전송제어 프로토콜)는 신뢰성이 없는 인터넷을 통해 종단간에 신뢰성 있는 바이트 스트림을 전송하도록 특별히 설계되었다.
  • TCP 서비스는 송신자와 수신자 모두가 소켓이라고 부르는 종단점을 생성함으로써 이루어진다.
  • TCP 에서 연결 설정(connection establishment)는 3-way handshake를 통해 행해진다.
  • 모든 TCP 연결은 전이중(full-duplex), 점대점(point to point)방식이다.
  • 전이중이란 전송이 양방향으로 동시에 일어날 수 있음을 의미하며 점대점이란 각 연결이 정확히 2 개의 종단점을 가지고 있음을 의미한다.
  • TCP 는 멀티캐스팅이나 브로드캐스팅을 지원하지 않는다.

 

 

 

 

4. TCP 흐름제어 / 혼잡제어

 

4-1 : TCP 통신이란?

  • 네트워크 통신에서 신뢰적인 연결방식
  • TCP는 기본적으로 unreliable network에서, reliable network를 보장할 수 있도록 하는 프로토콜
  • TCP는 network congestion avoidance algorithm을 사용
  • reliable network를 보장한다는 것은 4가지 문제점 존재
  • 손실 : packet이 손실될 수 있는 문제
  • 순서 바뀜 : packet의 순서가 바뀌는 문제
  • Congestion : 네트워크가 혼잡한 문제
  • Overload : receiver가 overload 되는 문제

 

 

 

4-2 : 흐름제어/혼잡제어란?

 

4-2-1 : 흐름제어 (endsystem 대 endsystem)

  • 송신측과 수신측의 데이터 처리 속도 차이를 해결하기 위한 기법
  • Flow Control은 receiver가 packet을 지나치게 많이 받지 않도록 조절하는 것
  • 기본 개념은 receiver가 sender에게 현재 자신의 상태를 feedback 한다는 점
  • Stop and Wait : 매번 전송한 패킷에 대해 확인 응답을 받아야만 그 다음 패킷을 전송하는 방법
  • Sliding Window (Go Back N ARQ) : 수신측에서 설정한 윈도우 크기만큼 송신측에서 확인응답 없이 세그먼트를 전송할 수 있게 하여 데이터 흐름을 동적으로 조절하는 제어기법으로 전송은 되었지만, acked를 받지 못한 byte의 숫자를 파악하기 위해 사용하는 protocol

 

4-2-2 : 혼잡제어 

  • 송신측의 데이터 전달과 네트워크의 데이터 처리 속도 차이를 해결하기 위한 기법
  • 네트워크 내에 패킷의 수가 과도하게 증가하는 현상을 혼잡이라 하며, 혼잡 현상을 방지하거나 제거하는 기능을 혼잡제어라고 한다.
  • 흐름제어가 송신측과 수신측 사이의 전송속도를 다루는데 반해, 혼잡제어는 호스트와 라우터를 포함한 보다 넓은 관점에서 전송 문제를 다루게 된다.
  • AIMD(Additive Increase / Multiplicative Decrease) : 처음에 패킷을 하나씩 보내고 이것이 문제없이 도착하면 window 크기(단위 시간 내에 보내는 패킷의 수)를 1씩 증가시켜 가며 전송하는 방법
  • Slow Start (느린 시작) : AIMD와 마찬가지로 패킷을 하나씩 보내면서 시작하고, 패킷이 문제없이 도착하면 각각의 ACK 패킷마다 window size를 1씩 늘려준다. 즉, 한 주기가 지나면 window size가 2배로 된다.
  • Fast Retransmit (빠른 재전송) : 패킷을 받는 쪽에서 먼저 도착해야 할 패킷이 도착하지 않고 다음 패킷이 도착한 경우에도 ACK 패킷을 보내게 된다.
  • Fast Recovery (빠른 회복) : 혼잡한 상태가 되면 window size를 1로 줄이지 않고 반으로 줄이고 선형증가시키는 방법이다. 혼잡 상황을 한번 겪고 나서부터는 순수한 AIMD 방식으로 동작하게 된다.

 

 

 

4-3 : 전송의 전체 과정

  1. Application layer : sender application layer가 socket에 data를 씀.
  2. Transport layer : data를 segment에 감싼다. 그리고 network layer에 넘겨줌.
  3. 그러면 아랫단에서 어쨌든 receiving node로 전송이 됨. 이때, sender의 send buffer에 data를 저장하고, receiver는 receive buffer에 data를 저장함.
  4. application에서 준비가 되면 이 buffer에 있는 것을 읽기 시작함.
  5. 따라서 flow control의 핵심은 이 receiver buffer가 넘치지 않게 하는 것임.
  6. 따라서 receiver는 RWND(Receive WiNDow) : receive buffer의 남은 공간을 확보함

 

 

 

 

 

5. HTTP와 HTTPS

 

5-1 : HTTP(HyperText Transfer Protocol)

  • 인터넷상에서 클라이언트와 서버가 자원을 주고받을 때 쓰는 통신 규약
  • HTTP는 텍스트 교환이므로, 누군가 네트워크에서 신호를 가로채면 내용이 노출되는 보안 이슈가 존재한다.

 

▣ HTTP 는 평문 통신이기 때문에 도청이 가능하다.

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

 

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

  • 리퀘스트가 오면 상대가 누구든지 무언가의 리스폰스를 반환한다.

 

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

  • 여기서 완전성이란 정보의 정확성을 의미한다.
  • 서버 또는 클라이언트에서 수신한 내용이 송신측에서 보낸 내용과 일치한다라는 것을 보장할 수 없는 것이다.

 

 

--- 이런 보안 문제를 해결해 주는 프로토콜이 'HTTPS' ---

 

 

 

5-2 : HTTPS(HyperText Transfer Protocol Secure)

  • 인터넷상에서 정보를 암호화하는 SSL 프로토콜을 사용해 클라이언트와 서버가 자원을 주고받을 때 쓰는 통신 규약
  • HTTP 에 암호화와 인증, 그리고 완전성 보호를 더한 HTTPS
  • HTTPS는 텍스트를 암호화한다. (공개키 암호화 방식으로!) 
  • HTTPS 의 SSL 에서는 공통키 암호화 방식과 공개키 암호화 방식을 혼합한 하이브리드 암호 시스템을 사용한다.
  • 공통키를 공개키 암호화 방식으로 교환한 다음에 다음부터의 통신은 공통키 암호를 사용하는 방식이다.
  • HTTP 는 원래 TCP 와 직접 통신했지만, HTTPS 에서 HTTP 는 SSL 과 통신하고 SSL 이 TCP 와 통신하게 된다. SSL 을 사용한 HTTPS 는 암호화와 증명서, 안전성 보호를 이용할 수 있게 된다.
  • 평문 통신에 비해서 암호화 통신은 CPU나 메모리 등 리소스를 더 많이 요구한다. 통신할 때마다 암호화를 하면 추가적인 리소스를 소비하기 때문에 서버 한 대당 처리할 수 있는 리퀘스트의 수가 상대적으로 줄어들게 된다.
  • 하지만 최근에는 하드웨어의 발달로 인해 HTTPS를 사용하더라도 속도 저하가 거의 일어나지 않으며, 새로운 표준인 HTTP 2.0을 함께 이용한다면 오히려 HTTPS가 HTTP보다 더 빠르게 동작한다. 
  • 따라서 현재 모든 웹 페이지에서 HTTPS를 적용하는 방향으로 바뀌어가고 있다.

 

 

 

 

 

6. 웹 통신의 큰 흐름

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

 

in 브라우저

  1. url 에 입력된 값을 브라우저 내부에서 결정된 규칙에 따라 그 의미를 조사한다.
  2. 조사된 의미에 따라 HTTP Request 메시지를 만든다.
  3. 만들어진 메시지를 웹 서버로 전송한다.

이때 만들어진 메시지 전송은 브라우저가 직접하는 것이 아니다.

브라우저는 메시지를 네트워크에 송출하는 기능이 없으므로 OS에 의뢰하여 메시지를 전달한다.

우리가 택배를 보낼 때 직접 보내는 게 아니라, 이미 서비스가 이루어지고 있는 택배 시스템(택배 회사)을 이용하여 보내는 것과 같은 이치이다.

단, OS에 송신을 의뢰할 때는 도메인명이 아니라 ip주소로 메시지를 받을 상대를 지정해야 하는데, 이 과정에서 DNS서버를 조회해야 한다.

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

  1. 프로토콜 스택(운영체제에 내장된 네트워크 제어용 소프트웨어)이 브라우저로부터 메시지를 받는다.
  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. 왔던 방식대로 응답 메시지가 클라이언트에게 전달된다.

 

 

 

 

 

 

 

 

저작자표시 (새창열림)

'다짐하자 > 출근 준비' 카테고리의 다른 글

[ 클라우드 솔루션 ] 클라우드 서비스  (0) 2023.02.05
발표 준비 - CRM과 ERP 정의와 사용 목적 / 차이점  (0) 2023.02.01
22.01.25 - [ 자료구조 ] DataStructure  (0) 2023.01.25
22.01.24 - [ 개발상식 ] Development common sense  (0) 2023.01.24
23.01.20 ~ 01.23 - [ 설과 함께 찾아온 코로나 ]  (0) 2023.01.24

'다짐하자/출근 준비'의 다른글

  • 현재글22.01.26 - [ 네트워크 ] Network

관련글

댓글

티스토리툴바