Skip to content

Latest commit

 

History

History
206 lines (120 loc) · 8.91 KB

1.인터넷네트워크.md

File metadata and controls

206 lines (120 loc) · 8.91 KB

인터넷이 어떤식으로 통신이 일어나는지 알아봐야 한다. HTTP 웹에 대해서 공부를하는데 왜 인터넷 네트워크에 대해 알아봐야할까?

결국 웹이나 HTTP 도 전부 인터넷 네트워크 망에서 동작하는 것이기 때문

HTTP를 위한 사전 기본학습이기 때문에 조금 간단히 알아보고 가자

우선 인터넷 통신에 대해서 알아봐야한다.

우선 궁금증이 하나 생긴다. 수많은 중간노드(서버)를 거쳐서 메세지가 안전하게 넘어가야하는데 어떤 규칙으로 어떻게 넘어갈까?

image

그것을 알기 위해서는 IP(인터넷 프로토콜)이라고 하는 것부터 천천히 살펴보자

IP(인터넷 프로토콜)

###무엇인가

인터넷을 통해 메세지를 전송하려면 최소한의 규칙이 필요하다 클라이언트 와 서버 모두 아이피라고 하는 주소가 있어야 한다는 것이다.

IP라는 인터넷 프로토콜의 역할은

  • 지정한 IP주소에 데이터를 전달
  • 패킷이라는 통신 단위로 데이터 전달

이다. 이제 전달하고자하는 메세지를 그냥 보내는 것이 아니라 IP 패킷이라고 하는 규칙으로 감싸서 보내게 되는데,

이게 뭐냐면 메세지 밖에 '나의 IP' 그리고 '목적지 IP'를 두개를 적는것이다.

image

출발지에서 목적지 IP로 아이피 프로토콜에 의해서 목적지를 향해 서로 노드들이 패킷을 던지면서 목적지에 도착하고

image

서버쪽에서 패킷을 받았으면 반대로 똑같이 받았다는 메세지와 함께 클라이언트 쪽으로 노드들을 통해 던지면서 받았다는 응답을 건넨다.

참고로 출발에서 목적지로 가는 방법(노드간의 경로)와 목적지에서 출발지로 가는 방법은 다를 수 있다.

하지만 이러한 IP 프로토콜(=Internet Protocol)만으로는 한계가 있다.

IP 프로토콜의 한계

  1. 비연결성
    • 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송
  2. 비신뢰성
    • 중간에 패킷이 사라지면?
    • 패킷이 순서대로 안오면?
  3. 프로그램 구분
    • 같은 IP를 사용하는 서버에서 통신하는 애플리케이션이 둘 이상이면?

클라이언트는 대상 서버가 패킷을 받을 수 있는 상태인지 모름

image

인터넷은 서로 다른 서버를 거치게 되는데 중간 노드 서버가 다운이 되면 데이터가 소실될수 있는 문제가 있다.

image

또한 패킷의 용량이 크게 되면 메세지가 (1500바이트)가 넘는다면 끊어서 보내게 되는데 이때 끊어서 가게되는 데이터는 연결성이 보장되지 않을 수 있다.

이것들을 해결해 줄 수 있는게 바~~~로 TCP/UDP 이다.

TCP, UDP

패킷 소실, 순서 문제 발생 이런것들을 TCP가 해결해준다!

image

인터넷 프로토콜 스택의 4계층

  • 애플리케이션 계층 HTTP FTP
  • 전송 계층 TCP UDP
  • 인터넷 계층 IP
  • 네트워크 인터페이스 계층

아이피라는 거를 위에 살짝 TCP라는 것을 올려서 보완해준다고 일단 간단히 생각하면 된다.

자세히 보자

image

  1. 소켓 라이브러리(각 언어 각 프로그램마다 존재)를 통해서 OS 계층에 Hello라는 메세지를 넘김

  2. 그러면 OS 계층에서 TCP가 메세지를 한번 싹 감싼다(TCP 세그먼트라고 일컫는데 TCP 세그먼트로 감싼다).

  3. 그리고 나서 TCP아래 IP 계층에서 IP 프로토콜로 한번 더 감싼다.

  4. 그리고 이제 이게 네트워크 인터페이스 랜카드를 통해서 Ethernet Frame(Mac ID etc.)에 쌓여져 전송된다.

      + 패킷( package + bucket)

TCP 세그먼트 : 출발지 port 목적지 port 전송제어 순서 검증 정보 가 들어감

TCP 특징

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

  • 연결 지향적 - TCP 3-way handshake

  • 데이터 전달 보증

  • 순서 보장

  • 신뢰할 수 있는 프로토콜

  • 현재는 대부분 TCP 사용

TCP 3 way handshake

image

클라이언트에서 서버로 일단 SYN 보냄

서버에서 왔네? ACK 라는 메세지를 클라이언트에 보내면서 SYN 보내고

클라이언트에서도 ACK를 보내면서 서로 연결!

서로 둘이 연결이 됬구나 인식하게되고 연결 후에 데이터 전송 참고로 최적화가 되어서 ACK 와 함께 데이터 전송 이 가능

TCP 연결이 되었다? 하지만 진짜 연결이 된게 아니다. 물리적인 연결이 아니라는 소리이다. 논리적인 연결을 의미 한다. 연결이 됬구나라는 것은 나를 위한 전용 랜선 연결이 된 것은 아니다. 참고하자.

데이터 전달 보증

image

  1. 데이터 전송
  2. 데이터 잘 받았다고 응답

순서 보장

image 패킷 1 패킷 2 패킷 3

패킷 1 패킷 3 패킷 2 -> 다버리고 패킷 2번부터 다시보내

패킷 2부터 다시보낸다.

물론 서버에서 최적화 할 수 있겠지? 좀 패킷좀 모아놨다가 1번 3번 순으로 들어오면 1번 2번 3번순으로 바꿔서 받을수 있겠지만 일단 기본 내부 구조적으로 서버는 클라이언트에게 2번부터 다시보내달라는 요청을 한다 그럼 클라이언트는 2번부터 다시보낸다.

TCP 세그먼트 안에는 전송제어정보, 순서정보, 검증정보가 들어있기 때문 에 이런것들이 가능한것이다. 그래서 TCP를 신뢰할수 있는 프로토콜이라 하는 것이다.

UDP특징

UDP는 TCP와 마찬가지로 IP계층 위에있는 프로토콜 이지만 UDP는 기능이 없다.

기능이 없다? = 그렇기에 하얀 도화지에 비유 한다.

  • TCP 3-way handshake X
  • 데이터 전달 보증 X
  • 순서 보장 X

But! 데이터 전달 및 순서가 보장되지 않지만, 단순하고 빠름

IP와 거의 같다. + PORT + 체크섬 정도만 추가 (주고 받는 메세지에 대해서 올바른 제대로된 정보가 맞는지 검증해주는 데이터)

애플리케이션에서 추가 작업 필요

TCP는 다좋은데 3 Way handshake 하려면 시간 걸리겠죠? TCP는 다좋은데 3 Way handshake 하려면 시간 걸릴 수 있다. 세그먼트나 서로 주고 받는게 있다면 무거워지고(용량이 늘어나고) 느려(전송속도도 떨어지고) 진다.

TCP는 이미 만연해 있는 프로토콜이기에 손을 댈수 없다.

하지만 만약에 TCP보다 내가 더 최적화 할수 있다면 UDP를 손을 대면 된다. 최근 웹브라우저에서 HTTP 통신을 할때 3.0스펙에서는 UDP로 주고 받음

PORT

한번에 둘 이상 연결해야 하면? 어떻게 구분해야할까?

출발지 PORT 목적지 PORT 가있다.

이제는 TCPIP 패킷이라고 할것이고 출발지IP|PORT, 목적지 IP|PORT 전송 데이터로 구분할것이다. 같은 아이피내에서 프로세스를 구분하기 위해 있는것이 포트! IP는 아파트 동 PORT는 각 아파트 안의 호!

065535 할당 가능 01023 잘 알려진 포트 사용하지 않는 것이 좋음

FTP - 20,21 TELNET - 23 HTTP - 80 HTTPS - 443

DNS

기억하기 어려움 IP는 바뀔 수 있음

도메인 네임 시스템

전화번호부 도메인 명을 IP주소로 변환

DNS서버에 도메인 명을 등록할(살) 수 있다

되게 복잡한 인터넷 망에서 메세지를 보내기 위해서 IP(Internet Protocol)이라는 IP가 있어야 한다. IP 프로토콜 만으로는 메세지가 제대로 갔는지 포트도 없어서 어디로 갔는지 모르지만 TCP 프로토콜이 해결해 준다. UDP도 있는데 PORT만 추가되는 백지상태라고 보면된다. UDP 프로토콜위에 내가 애플리케이션에서 기능을 확장해 볼 수 있다. 포트는 같은 아이피 안에서 동작하는 애플리케이션을 구분하기 위해서 사용하고 아이피는 변하기 쉽고 외우기 어려운데 도메인명을 등록해서 사용할수 있도록 도와주는게 DNS