본문 바로가기

CS/네트워크 기초

네트워크 통신 과정

 

DHCP[ip] -> ARP[ip-mac] -> DNS[udp] -> HTTP[tcp]

 

DHCP

ARP

DNS

HTTP

 

DHCP란

Dynamic Host Configuration Protocol 약자이다.
DHCP란 호스트의 IP주소와 각종 TCP/IP 프로토콜의 기본 설정을 클라이언트에게 자동적으로 제공해주는 프로토콜을 말합니다

 

DHCP 프로토콜의 메세지는 Discover,offer,request,ack 4개의 형태로 구성되어있다.

DHCP프로토콜은 3계층 네트워크 계층에서 UDP로 전송한다.

DHCP Discover은 클라이언트가 DHCP서버를 찾기 위해 메시지를 송신하는 것을 말한다.

2계층 Ethernet 프로토콜의 구성 중 도착지 Mac address를 최대값 즉 (ff:ff:ff:ff:ff:ff)로 할당되어 브로드 캐스트를 진행한다.

DHCP의 구성이다.

위 사진은 DHCP헤더의 구성이다.

Discover의 주요 항목은 클라이언트의 맥주소이다. 

 

브로드캐스트란?

클라이언트에 직접적으로 연결된 모든 노드에 해당 메시지를 뿌리는 것을 말한다. 

 

UDP란?

User Datagram Protocol 의 약자이다.

 UDP,TCP는 메시지를 정확한 프로세스에 전달시킬 수 있으며 Port 번호가 필요하다.

UDP 프로토콜의 주요구성은 Source Port,Destination Port,Length,Checksum 이며

Checksum은 데이터가 전송 중에 손상되지않고 원본과 동일한지를 확인하는 기능이다.

 

 

DHCP offer란?

 

DHCP offer는 클라이언트의 메시지를 받은 DHCP서버가 IP및 각종의 네트워크 정보를 클라이언트에게 전달하는 과정이다.

 

2계층 데이터 링크 계층의 구성을 보자.

offer 의 2계층을 보면 아까와는 다르게 도착지의 Mac 주소가 (ff:ff:ff:ff:ff:ff)가 아닌 것을 확인 할 수 있다.

브로드 캐스트에서는 아이피도 최대값으로 전송하는 것 을 확인할 수 있다.

왜냐하면 discover 단계에서 클라이언트의 IP와 맥주소가 입력되어있기 때문에 해당 메시지를 전달받은 DHCP 서버는 

해당 내용을 목적지로 바꾸어 전송하기 때문이다. 

 

offer의 헤더 정보

Discover 과 offer의 헤더의 구성은 같지만 전달하는 데이터가 달라진다.

Your IP  address 는 DHCP 서버가 클라이언트에게 할당해줄 IP의 주소이다.

다른 부분은 option 인데 서브넷 마스크의 정보 등 DHCP의 아이피 주소 등을 같이 들어있는 것을 확인할 수 있다. 

Padding 부분은 헤더의 길이를 맞추기위해 공간을 채워넣은 것이다. 

 

3번째 부분은 DHCP request 이다.

 

offer의 정보를 전달받은 클라이언트가 다시 DHCP 서버에 응답을 하는 패킷이다.

DHCP 프로토콜의 헤더를 다시한번 살펴보면 offer의 데이터 중 Your IP address 의 값이 

Requested IP address에 입력되어있는 것을 확인할 수 있다.

Request는 해당 정보를 할당받겠다는 클라이언트의 확인이다.

Ps. 2개의 DHCP서버가 연결되어있다면 클라이언트는 전달받은 두개의 네트워크 정보중 하나를 설정해 한쪽에만 request 패킷을 전송한다.

 

4번 DHCP Ack란?

 

request 를 전송받은 DHCP서버가 해당 네트워크 정보를 클라이언트에게 할당한다는 패킷이다.

 

DHCP헤더 정보를 살펴보면  Offer의 헤더 정보와 같은 값인 것을 확인할 수 있다.

왜냐하면 Offer에서 클라이언트에 전달했던 네트워크 정보를 DHCP 서버가 클라이언트에게 할당했음을 확인하는 응답 패킷이기 때문이다.

 

이 과정이 끝이나면 클라이언트는 네트워크를 사용할 수 있게된다.

 

ARP 란?

Address Resolution Protocol 의 약자이다.

ARP 프로토콜이 하는 일은 네트워크 상의 IP Address를 물리적 네트워크 주소 즉 Mac주소로 대응하기 위해 사용된다.
ARP 는 로컬네트워크상의 통신을 위한 프로토콜이다. 

 

ARP의 헤더 데이터

ARP의 Ethernet 프로토콜의 데이터를 간단하게 살펴보면 맥주소를 알지못해 브로드캐스트 값으로 입력되어 있는 것을 확인할 수 있다.

하지만 ARP 헤더를 확인하면 브로드 캐스트와는 다르게 Target IP address가 지정되어있는 것을 확인할 수 있다.

sender 의 mac과ip 주소는 클라이언트의 주소이다.

 

ARP응답 패킷의 헤더

ARP프로토콜의 응답패킷의 헤더를 확인해보면 sender와 Target의 값이 아까와는 반대로 입력되어 있는 것을 확인 할 수 있고 Mac 주소의 값이 입력되어있는 것을 확인할 수 있다.

 

ARP를 이용해 게이트웨이의 Mac Address를 알 수 있다.(직접적으로 연결된 노드의 Mac주소를 알 수 있다,)

 

DNS란?

 Domain Name System 프로토콜의 약자이다.

사람이 읽을 수 있는 도메인 주소를 머신이 읽을 수 잇는 IP주소로 변환한다.

DNS 프로토콜은 신뢰성이 중요하지 않아 UDP 프로토콜을 사용하여 전송한다.

 

UDP 프로토콜을 사용해서 DNS서버 53번 포트를 목적지로 하고있는 것을 확인할 수 있다.

DNS의 헤드 구조는

Transaction id(2byte) : 통신에 대한 식별번호

Flag(2byte) : DNS 메세지 타입

questions(2byte) : 질의 갯수

- 요청 필드의 갯수

- 질의 하려는 도메인의 갯수와 일치

- 데이터의 크기와 커지면 자동으로 TCP통신으로 전환된다.

answer(2byte) : 요청 필드의 갯수

authority(2byte) : 권한 필드의 갯수

additional(2byte) : 추가적인 정보를 표현하는 필드의 갯수

가 고정이지만 필드정보에 따라 전체 사이즈가 가변적이다.

 

해당  Queries 부분을 확인해보면

찾으려하는 도메인 주소가 입력되어있음을 확인할 수 있다.

name 부분에 입력된 도메인 주소로 해당 서버의 IP를 도메인 서버에서 가져온다.

 

DNS 프로토콜의 response 는 쿼리에 대한 응답을 해주는 패킷이다.

헤더의 구성 살펴보면 아까와는 다르게 Answer RRs 가 1로 변경되어 있는 것을 확인할 수 있다.

즉 1개의 결과 필드 값이 나온 걸 알 수 있다.

Answers의 구성을 확인해보면 아까 알려고 하던 chrissanders.org의 어드레스 주소가 입력되어 있는 것을 확인할 수 있다.

 

우리가 검색한 도메인을 DNS서버에서 검색해 해당 도메인 서버의 아이피를 찾아 접속한다.

 

HTTP란?

참조 블로그 victorydntmd.tistory.com/286?category=719464

Hyper Text Transfer Protocol의 약자이다.

인터넷에서 데이터를 주고받을 수 있는 프로토콜이다.

 

HTTP 동작

클라이언트 즉, 사용자가 브라우저를 통해서 어떠한 서비스를 url을 통하거나 다른 것을 통해서 요청(request)을 하면 서버에서는 해당 요청사항에 맞는 결과를 찾아서 사용자에게 응답(response)하는 형태로 동작한다.

  • 요청 : client -> server
  • 응답 : server -> client

HTML 문서만이 HTTP 통신을 위한 유일한 정보 문서는 아니다.
Plain text로 부터 JSON 데이터 및 XML과 같은 형태의 정보도 주고 받을 수 있으며, 보통은 클라이언트가 어떤 정보를 HTML 형태로 받고 싶은지, JSON 형태로 받고 싶은지 명시해주는 경우가 많다.

 

HTTP의 특징

  • HTTP 메시지는 HTTP 서버와 HTTP 클라이언트에 의해 해석이 된다.
  • TCP/ IP를 이용하는 응용 프로토콜이다.
    (컴퓨터와 컴퓨터간에 데이터를 전송 할 수 있도록 하는 장치로 인터넷이라는 거대한 통신망을 통해 원하는 정보(데이터)를 주고 받는 기능을 이용하는 응용 프로토콜)
  • HTTP는 연결 상태를 유지하지 않는 비연결성 프로토콜이다.
    (이러한 단점을 해결하기 위해 Cookie와 Session이 등장하였다.)

비연결성 ( Connectionless )

비연결성은 클라이언트와 서버가 한 번 연결을 맺은 후, 클 라이언트 요청에 대해 서버가 응답을 마치면 맺었던 연결을 끊어 버리는 성질을 말합니다.

 

장점

연결을 유지하기 위한 리소스를 줄이면  더 많은 연결을 할 수 있는 비연결적인 특징을 갖는다.

 

단점

서버는 클라이언트를 기억하고있지않기때문에 동일한 클라이언트의 모든 요청에도 매번 새로운 연결을 시도/해제의 과정을 거쳐야하므로 연결/해제에 대한 오버헤드가 발생한다.

 

무상태(Stateless)

위의 connectionless로 인해 서버는 클라이언트를 식별할 수 없는데,이를 Stateless라고 한다.

클라이언트의 상태를 모른다는 것은 같은 행위를 반복한다는 이야기이다.

 

상태를 기억하는 방법 - 쿠키

HTTP는 이러한 문제점을 해결하기 위해 브라우저 단에서 쿠키라는 것을 저장하여 서버가 클라이언트를 식별할 수 있도록 합니다.

 

상태를 기억하는 방법 - 세션

쿠키는 사용자 정보가 브라우저에 저장되기 때문에 공격자로부터 위변조의 가능성이 높아 보안에 취약합니다.

이와 달리 세션은 브라우저가 아닌 서버단에서 사용자 정보를 저장하는 구조입니다.

따라서 쿠키보다는 안전하다고 할 수 있습니다.

 

4) 상태를 기억하는 방법 - 토큰을 사용하는 OAuth, JWT

쿠키와 세션의 문제점들을 보완하기 위해 토큰( Token )기반의 인증 방식이 도입되었습니다.

토큰 기반의 인증 방식의 핵심은 보호할 데이터를 토큰으로 치환하여 원본 데이터 대신 토큰을 사용하는 기술입니다.

그래서 중간에 공격자로부터 토큰이 탈취당하더라도 데이터에 대한 정보를 알 수 없으므로, 보안성을 높은 기술이라 할 수 있습니다.

대표적으로는 OAuth JWT이 있습니다.

 

Request Method 

  • GET : 자료를 요청할 때 사용
  • POST : 자료의 생성을 요청할 때 사용
  • PUT : 자료의 수정을 요청할 때 사용
  • DELETE : 자료의 삭제를 요청할 때 사용

해당 이미지를 확인하면 HTTP 프로토콜은 HTTP 서버의 80번 포트를 목적지로 하고있는 것을 확인할 수 있다.

위에서 본 GET 메소드를 이용해 HTTP서버에서 해당 소스코드를 받고자하는 request 패킷이다.

1번째 줄의 GET은 메소드이고 다음 download.html은 사이트의 주소 다음 오는 HTTP/1.1은 현재 HTTP의 버전을 나타낸다.

 

클라이언트가 요청한 코드가 이상없이 전송이 완료된 것을 확인해주는 패킷이다.

HTTP 프로토콜의 헤더를 확인하면 1번째 라인에 HTTP/1.1 200 ok라고 기술되어있는데 이부분의 200 ok는 해당 요청이 이상없이 실행되었다는 응답이다.

이후 헤더 데이터 뒤에는 HTML코드가 담겨있는데 이 코드를 브라우저가 화면에 렌더링한다.

 

HTTP 응답 상태코드

  • 100 - 109
    • 메시지 정보
  • 200 - 206
    • 요청 성공
  • 300 - 305
    • 리다이렉션
  • 400 - 415
    • 클라이언트 에러
    • 404 에러는 리퀘스트 요청이 잘못되었다는 의미이다.
    • 403은 권한이 주어지지 않았다는 에러
  • 500 - 505
    • 서버에러

HTTPS란?

HTTPS는 SSL/TLS를 알아야한다.

SSL/TLS는 암호화 프로토콜을 이야기합니다. 이에 대해서 인증서가 필요합니다.

SSL/TLS는 공개키 암호화기능을 사용하는데 공개키 암호화란 비대칭형 암호화를 말합니다.

SSL/TLS의 인증방식

공개키 암호화 방식에선 공개키와 개인키(비공개 키)가 있습니다.

공개키 A와 개인키 B를 예시로 든다면 공개키 A로 암호화를 할 경우 개인키 B로만 복호화가 가능합니다.

즉 공개키 A로도 복호화가 불가능하다가 결론입니다.

 

서버가 한쌍이되는 소수 2개를 가지고 공개키와 개인키를 만들고 공개키를 서버에 접속하는 모든 클라이언트에게 보냅니다.

그 후 클라이언트는 서버에게 공개키로 암호화한 정보를 보내면 서버는 개인키로 해당 정보를 복호화해 저장합니다.

하지만 이 방식에는 중간에서 패킷을 가로챌 경우 대응할 방법이 없다는 것입니다.

그래서 인증서라는 것이 등장합니다.

대체로 국가산하기관인 CA기관에서 각 서버를 운영하는 기업에게 인증서를 발급합니다. 

인증서 발급과정에는 SITE의 정보와 해당 서버의 공개키를 CA가 받아 CA기관의 개인키로 두개를 암호화해 인증서를 만듭니다.

현재 사용중인 브라우저들에는 CA기관의 공개키가 내장되어있습니다.

해당 인증서를 발급받은 서버가 클라이언트의 접속 요청을 받으면 인증서를 보내주고 

클라이언트는 해당 인증서를 브라우저에 내장되어있는 CA기관의 공개키로 복호화를하여 서버의 공개키를 취득합니다.

해당 서버의 개인키는 서버만 관리하고 있기때문에 정보가 해킹당할 가능성은 현저히 줄어들게됩니다.

클라이언트는 대칭키를 생성해 서버의 공개키로 암호화해 서버에 전송합니다.

서버는 전달받은 암호화데이터를 개인키로 복호화해 클라이언트가 전송해준 대칭키를 획득하게 되고

그 이후부터는 서버와 클라이언트는 대칭키로 통신하게 됩니다.

 

공개키 방식은 소인수분해 방식의 알고리즘을 가지고있고 처리속도가 느리다는 단점을 가지고 있습니다.

장점으로는 현재로서는 키가 없다면 복호화하기 힘들다는 것입니다.

 

URI란?

Uniform Resource Identifiers 의 약자이다.

URI이란, 웹 서버가 리소스를 고유하게 식별할 수 있도록 하는 것으로써, URL과 URN 두 가지가 있는데 일반적으로 URL을 사용합니다.

  • URL은 특정 서버의 한 리소스에 대해 구체적인 위치를 서술합니다.
  • URN은 리소스가 어디에 위치해 있든 찾을 수 있는 방식을 말합니다. 

TCP란?

Transmission Control Protocol의 약자이다.

TCP프로토콜의 연결을 위해서는 연결 설정 과정(3-way handshake) 을 실행해야한다.

TCP는 4계층 트랜스포트 계층에서 사용되는 프로토콜이다.

3way handshake
TCP의 헤더 구조
TCP통신 연결을 하기 위해 syn 패킷을 보내는 것을 확인

 해당 TCP 헤더의 Syn의 값을 보냅니다.

클라이언트에서 TCP통신 연결을 수립하기위해 전송한 패킷을 받아 잘 받았다는 응답을 하기위해 Ack 값을 입력해 응답한다. seq가 0이기 때문에 응답 메시지에서는 ack가 1로 온다. syn역시 1로 전송된다.

받은 syn 패킷의 응답하는 패킷이다.

받은 seq가 0이기 때문에 0+1의 ack값을 입력하고 Syn은 그대로 반환한다.

클라이언트에서 TCP통신을 연결하기 위해 전하는 마지막 응답.

클라이언트에서 마지막으로 전하는 패킷이다 받은 메시지의 ack를 seq로 설정하고 seq를 + 1한 값을 ack에 설정한 후 응답한다.

4-way handshake란

TCP와 연결을 해제하는 과정

 

 

1. 연결 지향 프로토콜

  • 물리적으로 전용회선이 연결되어 있는 것처럼 가상의 연결통로를 설정하여 통신하는 방식으로 가상의 연결통로를 가상회선이라 한다.
    • 가상회선방식 : 물리적으로 전용회선이 연결되어 있는 것처럼 논리적으로 동작하는 방식 
  • 논리적인 연결통로를 통해 데이터를 주고받음으로써 데이터의 전송순서를 보장해준다. 순서제어 라고도 한다.
  • 스트림 기반의 전송방식을 사용한다. 데이터를 임의의 크기로 나누어 연속해서 전송하는 방식을 사용한다.

2. 신뢰할 수 있는 프로토콜

  • 흐름제어
    • 상대방이 받을 수 있을 만큼만 데이터를 효율적으로 전송하는 것
    • 흐름제어를 위해 슬라이딩 윈도우(Sliding Window) 방식을 사용한다. 이는 상대방이 수신 가능한 크기(Window size) 내에서 데이터를 연속해서 전송하는 방식으로 매 세그먼트(Segment) 전송 시마다 수신확인응답(ACK)을 수신한 후 전송하게 되면 왕복시간(RTT : Round Trip Time)이 길 경우 단위 시간당 데이터 전송량이 매우 떨어지므로 효율적으로 전송하기 위해 상대방이 받을 수 있는 범위 내에서 연속적으로 전송한다.
  • 오류제어
    • 데이터의 오류나 누락없이 안전한 전송을 보장
    • 오류 또는 누락 발생 시 재전송을 수행하여 이를 보정
  • 혼잡제어
    • 네트워크의 혼잡 정도에 따라 송신자가 데이터 전송량을 제어하는 것을 말한다.
    • 혼잡정도에 대한 판단기준은 데이터의 손실 발생 유무로 판단한다. 전송한 데이터에 누락이 발생하면 네트워크가 혼잡한 상태로 판단하여 전송량을 조절한다.

TCP 구조

 

 

    • Source Port(16 bits) : 출발지(송신) 포트 번호
    • Destination Port(16 bits) : 목적지(수신) 포트 번호
    • Sequence Number(32 bits) : 송신 데이터 순서 번호
      • 송신 시 전송하는 데이터의 시작 바이트 순번을 담는다. 바이트 순번은 전송하는 데이터의 바이트 단위로 부여하는 연속된 번호를 의미한다.
      • 연결설정 단계에서 초기 순서 번호를 상호간에 주고받는다, 초기 순서 번호는 0부터 시작하는 것이 아니라 임의의 수를 할당해서 사용한다.
    • Acknowledgment Number(32 bits) : 상대방이 다음에 전송할 순서 번호
      • 수신 확인 응답(ACK)과 함께 해당 필드에 상대방이 다음에 전송할 순서 번호를 담아서 보낸다.
    • HLEN(4 bits) : 헤더 길이
      • 4 bits 워드 단위로 표시(20 ~ 60 bytes)하며 기본 헤더 20 bytes와 옵션 헤더 최대 40 bytes로 구성된다.
    • Reserved(4 bits) : 예약
    • Control Flags(6 bits)
      • URG(Urgent pointer is valid) : 긴급 데이터 설정
      • ACK(Acknowledgment is valid) : 수신 확인 응답(ACK) 설정
      • PSH(Request for push) : 송수신 버퍼에 있는 데이터를 즉시 처리
      • RST(Reset the connection) : 연결 중단(강제 종료)
      • SYN(Synchronize sequence numbers) : 연결 설정
      • FIN(Terminate the connection) : 연결 종료 (정상 종료)
    • Window size(16 bits) 
      • 수신측에서 송신측에 보내는 Receiver window size로 수신버퍼의 여유공간 크기를 의미한다. 송신측에서는 상대방의 여유 공간 크기를 통해서 흐름제어를 수행할 수 있다.
      • 따라서 송신측에서는 상대방의 윈도우 사이즈 범위 내에서 수신측의 수신 확인 응답(ACK)을 기다리지 않고 연속적으로 전송할 수 있는데 이를 슬라이딩 윈도우 제어방식이라 한다.
    • Checksum(16 bits) : 헤더를 포함한 전체 세그먼트에 대한 오류를 검사하기 위한 필드
    • Urgent Pointer(16 bits) : 세그먼트가 긴급 데이터(URG 플래그 설정)를 포함하고 있는 경우에 사용되는 필드로 긴급 데이터의 위치값을 담고 있다.

'CS > 네트워크 기초' 카테고리의 다른 글

RSET API 와 RESTful 이란?  (0) 2021.02.02
웹 브라우저의 구성 요소와 요소별 특징  (0) 2021.02.01
TCP 패킷 분석  (0) 2021.01.28
DNS 패킷 분석  (0) 2021.01.28
와이어샤크 (Wireshark)로 ARP 분석  (0) 2021.01.27