시스코 교육 200-125 CCNA v3.0. 6일차: 빈칸 채우기(DHCP, TCP, 핸드셰이크, 공통 포트 번호)

오늘의 비디오 튜토리얼을 시작하기 전에 YouTube에서 제 강좌가 인기를 끌 수 있도록 기여해주신 모든 분들께 감사의 말씀을 전하고 싶습니다. 약 8개월 전에 시작했을 때는 그런 성공을 기대하지 않았습니다. 오늘 제 강의는 312724명이 조회했고 구독자 수는 11208명입니다. 나는 이 보잘것없는 시작이 이렇게 높은 곳에 도달할 것이라고는 꿈에도 생각지 못했습니다. 하지만 시간을 낭비하지 말고 바로 오늘 수업으로 넘어가겠습니다. 오늘 우리는 지난 7번의 비디오 강의에서 발생한 공백을 메울 것입니다. 오늘은 6일차지만 3일차는 3개의 동영상 강의로 나누어져 있으므로 오늘은 실제로 XNUMX번째 동영상 강의를 시청하게 됩니다.

오늘은 DHCP, TCP 전송, 가장 일반적인 포트 번호라는 3가지 중요한 주제를 다룰 것입니다. 우리는 이미 IP 주소에 대해 이야기했는데, IP 주소 구성에서 가장 중요한 요소 중 하나는 DHCP입니다.

DHCP는 Dynamic Host Configuration Protocol의 약자로 호스트의 IP 주소를 동적으로 구성하는 데 도움이 되는 프로토콜입니다. 우리 모두는 이 창을 본 적이 있습니다. "자동으로 IP 주소 받기" 옵션을 클릭하면 컴퓨터는 동일한 서브넷에 구성된 DHCP 서버를 찾아 IP 주소에 대한 다양한 패킷과 요청을 보냅니다. DHCP 프로토콜에는 6개의 메시지가 있으며 그 중 4개는 IP 주소 할당에 중요합니다.

첫 번째 메시지는 DHCP DISCOVERY 메시지입니다. DHCP 검색 메시지는 인사말 메시지와 유사합니다. 새 장치가 네트워크에 연결되면 네트워크에 DHCP 서버가 있는지 묻습니다.

슬라이드에 보이는 것은 장치가 DHCP 서버를 찾기 위해 네트워크의 모든 장치에 연결하는 브로드캐스트 요청처럼 보입니다. 제가 말했듯이 이것은 브로드캐스트 요청이므로 네트워크의 모든 장치가 이를 들을 수 있습니다.

네트워크에 DHCP 서버가 있으면 DHCP OFFER 제안이라는 패킷을 보냅니다. 제안이란 DHCP 서버가 검색 요청에 대한 응답으로 클라이언트에 구성을 보내 클라이언트에게 특정 IP 주소를 수락하도록 요청하는 것을 의미합니다.

DHCP 서버는 IP 주소(이 경우 192.168.1.2)를 예약하여 이를 제공하지 않고 장치에 대해 이 주소를 예약합니다. 동시에 제안 패키지에는 DHCP 서버의 자체 IP 주소가 포함되어 있습니다.

이 네트워크에 DHCP 서버가 두 개 이상 있는 경우 다른 DHCP 서버는 클라이언트의 브로드캐스트 요청을 수신하면 IP 주소(예: 192.168.1.50)도 제공합니다. 동일한 네트워크에 두 개의 서로 다른 DHCP 서버를 구성하는 것은 일반적이지 않지만 가끔 그런 일이 발생합니다. 따라서 DHCP 제안이 클라이언트에 전송되면 클라이언트는 2개의 DHCP 제안을 수신하고 이제 어떤 DHCP 제안을 수락할지 결정해야 합니다.

클라이언트가 첫 번째 애플리케이션을 수락한다고 가정해 보겠습니다. 이는 클라이언트가 말 그대로 "DHCP 서버 192.168.1.2에서 제공하는 IP 주소 192.168.1.1를 수락합니다"라는 DHCP REQUEST 요청을 보내는 것을 의미합니다.

요청을 받으면 192.168.1.1 DHCP 서버는 "알았어, 인정합니다"라고 응답합니다. 즉, 요청을 승인하고 이 DHCP ACK를 클라이언트에 보냅니다. 그러나 다른 DHCP 서버가 클라이언트를 위해 IP 주소 1.50을 예약했다는 것을 기억합니다. 클라이언트의 브로드캐스트 요청을 받으면 실패에 대해 알게 되고 다른 요청을 받으면 다른 클라이언트에 할당할 수 있도록 해당 IP 주소를 풀에 다시 넣습니다.

이는 IP 주소를 할당할 때 DHCP가 교환하는 4가지 중요한 메시지입니다. 다음으로 DHCP에는 2개의 추가 정보 메시지가 있습니다. 두 번째 단계의 DHCP OFFER 절에서 받은 것보다 더 많은 정보가 필요한 경우 클라이언트는 정보 메시지를 발행합니다. 서버가 DHCP 제안에 충분한 정보를 제공하지 않았거나 클라이언트가 제안 패킷에 포함된 것보다 더 많은 정보가 필요한 경우 추가 DHCP 정보를 요청합니다. 클라이언트가 서버에 보내는 메시지가 하나 더 있습니다. 이는 DHCP RELEASE입니다. 클라이언트가 기존 IP 주소를 해제하려고 함을 알려줍니다.

그러나 가장 자주 발생하는 일은 클라이언트가 DHCP RELEASE를 서버에 보낼 시간을 갖기 전에 사용자가 네트워크 연결을 끊는 것입니다. 이것은 우리가 하는 것처럼 컴퓨터를 끌 때 발생합니다. 이 경우 네트워크 클라이언트나 컴퓨터는 서버에 사용된 주소를 해제하라고 알릴 시간이 없으므로 DHCP RELEASE는 필수 단계가 아닙니다. IP 주소를 얻기 위해 필요한 단계는 DHCP 검색, DHCP 제공, DHCP 요청 및 DHCP 핸드셰이크입니다.

다음 강의에서는 DNCP 풀을 생성할 때 DHCP 서버를 구성하는 방법을 설명하겠습니다. 풀링이란 192.168.1.1 ~ 192.168.1.254 범위의 IP 주소를 할당하도록 서버에 지시하는 것을 의미합니다. 따라서 DHCP 서버는 풀을 생성하고 그 안에 254개의 IP 주소를 배치하며 이 풀에서만 네트워크의 클라이언트에 주소를 할당할 수 있습니다. 따라서 이는 사용자가 수행할 수 있는 관리 설정과 같습니다.

이제 TCP 전송을 살펴보자. 사진 속 '전화기'가 익숙하신지 모르겠지만, 저희는 어렸을 때 이 깡통을 끈으로 연결해 서로 이야기를 나누곤 했습니다.

불행히도 오늘날의 세대는 그러한 "럭셔리"를 감당할 여유가 없습니다. 요즘 아이들은 한 살 때부터 TV 앞에 있고, PSP를 합니다. 논란의 여지가 있을지도 모르지만 우리는 최고의 어린 시절을 보냈다고 생각합니다. 사실 우리는 밖에 나가서 게임도 하고, 오늘날의 아이들은 소파에서 멀어질 수 없습니다. .

내 아들은 이제 겨우 한 살이고 아이패드에 중독되어 있다는 것을 알 수 있습니다. 아직 아주 어리지만 오늘날의 아이들은 이미 전자 기기를 다루는 방법을 알고 태어났다고 생각합니다. 그래서 어렸을 때 우리가 놀 때 깡통에 구멍을 뚫고 그것을 끈으로 묶고 한 깡통에 무언가를 말하면 반대편에서 그 사람이 말하는 것을들을 수 있었다고 말하고 싶었습니다. 캔을 귀에 대는 것만으로도… 따라서 네트워크 연결과 매우 유사합니다.

오늘날에는 TCP 전송에도 실제 데이터 전송이 시작되기 전에 연결을 설정해야 합니다. 이전 강의에서 논의한 것처럼 TCP는 연결 지향 전송이고 UDP는 연결 지향 전송입니다. UDP는 내가 공을 던지는 곳이고 당신이 공을 잡을 수 있는지 확인하는 것은 당신에게 달려 있다고 말할 수 있습니다. 당신이 그것을 할 준비가 되었는지 아닌지는 내 문제가 아니며, 나는 그 사람을 그냥 떠날 것입니다.

TCP는 남자에게 말하고 공을 던질 것이라고 미리 경고하여 유대감을 형성한 다음 파트너가 공을 잡을 가능성이 더 높도록 공을 던지는 것과 비슷합니다. 따라서 TCP는 실제로 연결을 구축한 다음 실제 전송을 시작합니다.

그러한 연결이 어떻게 생성되는지 살펴보겠습니다. 이 프로토콜은 3방향 핸드셰이크를 사용하여 연결을 생성합니다. 이는 매우 기술적인 용어는 아니지만 오랫동안 TCP 연결을 설명하는 데 사용되어 왔습니다. 3방향 핸드셰이크는 송신 장치에 의해 시작되며 클라이언트는 SYN 플래그가 포함된 패킷을 서버에 보냅니다.

얼굴이 보이는 전경의 소녀가 장치 A이고, 얼굴이 보이지 않는 배경의 소녀가 장치 B라고 가정해 보겠습니다. 소녀 A는 소녀 B에게 SYN 패킷을 보내고 다음과 같이 말합니다. “좋습니다. 그렇다면 그 사람은 나와 소통하고 싶어합니다. 그러니 소통할 준비가 되었다고 대답해야죠!” 어떻게 하나요? 간단히 다른 SYN 패킷을 다시 보낸 다음 원래 SYN 패킷 수신을 나타내는 ACK를 보낼 수 있습니다. 그러나 서버는 ACK를 별도로 보내는 대신 SYN과 ACK를 포함하는 공통 패킷을 구성하여 네트워크를 통해 전송합니다.

따라서 이 시점에서 장치 A는 SYN 패킷을 보내고 SYN/ACK 패킷을 다시 받았습니다. 이제 장치 A는 장치 B에게 ACK 패킷을 보내야 합니다. 즉, 장치 B로부터 통신 설정에 대한 동의를 받았는지 확인해야 합니다. 따라서 두 장치 모두 SYN 및 ACK 패킷을 수신했으며 이제 연결이 설정되었다고 말할 수 있습니다. 즉, TCP 프로토콜을 사용하여 3단계 핸드셰이크가 완료되었다고 할 수 있습니다.

다음으로 TCP Windowing 기술을 살펴보겠습니다. 간단히 말하면 TCP/IP에서 송신자와 수신자의 성능을 협상하는 데 사용되는 방법입니다.

Windows에서 2GB 크기의 대용량 파일을 한 드라이브에서 다른 드라이브로 전송하려고 한다고 가정해 보겠습니다. 전송이 시작될 때 시스템은 파일 전송에 약 1년이 걸릴 것이라고 알려줍니다. 그러나 몇 초 후에 시스템은 스스로 정정하고 다음과 같이 말할 것입니다. "아, 잠깐만요. 6년이 아니라 1개월 정도 걸릴 것 같아요." 조금 더 시간이 지나면 Windows에서 "1달 안에 파일을 전송할 수 있을 것 같아요."라고 말할 것입니다. 이어 '6일', '3시간', '1시간', '20시간', '10분', '3분', '3분'이라는 메시지가 이어진다. 실제로 전체 파일 전송 프로세스는 2분 밖에 걸리지 않습니다. 어떻게 이런일이 일어 났습니까? 처음에 장치가 다른 장치와 통신을 시도하면 하나의 패킷을 보내고 확인을 기다립니다. 기기가 확인을 위해 오랜 시간을 기다리면 '이 속도로 2GB의 데이터를 전송해야 한다면 1년 정도 걸릴 것'이라고 생각합니다. 얼마 후, 귀하의 장치는 ACK를 수신하고 '좋아, 패킷 하나를 보냈고 ACK를 받았으니 수신자는 패킷 10개를 받을 수 있다'고 생각합니다. 이제 그에게 10패킷이 아닌 11패킷을 보내도록 노력하겠습니다.” 발신자는 10개의 패킷을 보내고 일정 시간이 지난 후 수신 장치로부터 ACK 확인을 받습니다. 이는 수신자가 다음 100번째 패킷을 기다리고 있음을 의미합니다. 보낸 사람은 다음과 같이 생각합니다. "좋아요. 받는 사람이 한 번에 100개의 패킷을 처리했으므로 이제 그에게 101개가 아닌 XNUMX개의 패킷을 보내려고 합니다." 그는 XNUMX개의 패킷을 보냈고 수신자는 이를 수신했으며 현재 XNUMX개의 패킷을 기다리고 있다고 응답합니다. 따라서 시간이 지남에 따라 전송되는 패킷 수가 증가합니다.

이것이 원래 언급된 것과 비교하여 파일 복사 시간이 급격히 감소하는 이유입니다. 이는 대량의 데이터를 전송할 수 있는 능력이 향상되었기 때문입니다. 그러나 전송량을 더 이상 늘릴 수 없는 시점이 온다. 10000개의 패킷을 보냈지만 수신자의 장치 버퍼는 9000개만 받아들일 수 있다고 가정하면, 수신자는 "9000개의 패킷을 수신했고 이제 9001을 수신할 준비가 되었습니다."라는 메시지와 함께 ACK를 보냅니다. 이를 통해 발신자는 수신 장치의 버퍼 용량이 9000에 불과하다는 결론을 내립니다. 이는 이제부터 한 번에 9000개 이하의 패킷을 보내겠다는 의미입니다. 이 경우 발신자는 남은 데이터 양을 9000개 패킷 단위로 전송하는 데 걸리는 시간을 빠르게 계산하여 3분을 줍니다. 이 XNUMX분은 실제 전송 시간입니다. 이것이 바로 TCP Windowing이 하는 일입니다.

이는 전송 장치가 최종적으로 실제 네트워크 용량을 이해하는 트래픽 조절 메커니즘 중 하나입니다. 왜 수신 장치의 용량이 어느 정도인지 사전에 합의하지 못하는지 궁금하시죠? 사실 이는 네트워크에 다양한 유형의 장치가 있기 때문에 기술적으로 불가능합니다. 당신이 아이패드를 가지고 있고 아이패드가 아이폰과 데이터 전송/수신 속도가 다르거나, 휴대폰 종류가 다르거나, 아주 오래된 컴퓨터를 가지고 있다고 가정해 봅시다. 따라서 모든 사람은 서로 다른 네트워크 대역폭을 가지고 있습니다.

이것이 바로 TCP Windowing 기술이 개발된 이유입니다. 데이터 전송이 저속으로 시작되거나 최소한의 패킷 전송으로 시작되어 트래픽 "창"이 점차 증가하는 것입니다. 5개의 패킷, 10개의 패킷, 1000개의 패킷, 10000개의 패킷, XNUMX개의 패킷을 보내고 "개방"이 특정 기간에 전송되는 최대 트래픽 양에 도달할 때까지 해당 창을 점점 더 천천히 엽니다. 따라서 Windowing 개념은 TCP 프로토콜 작동의 일부입니다.

다음으로 가장 일반적인 포트 번호를 살펴보겠습니다. 전형적인 상황은 데이터 센터와 같은 주 서버가 1개 있는 경우입니다. 여기에는 파일 서버, 웹 서버, 메일 서버 및 DHCP 서버가 포함됩니다. 이제 클라이언트 컴퓨터 중 하나가 그림 중앙에 있는 데이터 센터에 연결하면 파일 서버 트래픽을 클라이언트 장치로 보내기 시작합니다. 이 트래픽은 빨간색으로 표시되며 특정 서버의 특정 애플리케이션에 대한 특정 포트를 통해 전송됩니다.

서버는 특정 트래픽이 어디로 가야 하는지 어떻게 알았나요? 그는 대상 포트 번호를 통해 이를 알게 됩니다. 프레임을 보면 각 데이터 전송에서 대상 포트 번호와 소스 포트 번호에 대한 언급이 있음을 알 수 있습니다. 파란색과 빨간색 트래픽, 그리고 파란색 트래픽이 웹 서버 트래픽이라는 것을 알 수 있습니다. 둘 다 서로 다른 서버가 설치된 동일한 물리적 서버로 이동합니다. 데이터 센터인 경우 가상 서버를 사용합니다. 그러면 빨간색 트래픽이 해당 IP 주소를 가진 왼쪽 노트북으로 돌아가야 한다는 것을 어떻게 알았습니까? 그들은 포트 번호 덕분에 이를 알고 있습니다. Wikipedia 기사 "TCP 및 UDP 포트 목록"을 참조하면 모든 표준 포트 번호가 나열되어 있음을 알 수 있습니다.

이 페이지를 아래로 스크롤하면 이 목록이 얼마나 큰지 알 수 있습니다. 여기에는 약 61개의 숫자가 포함되어 있습니다. 000부터 1까지의 포트 번호가 가장 일반적인 포트 번호로 알려져 있습니다. 예를 들어 포트 1024/TCP는 ftp 명령 전송용이고, 포트 21는 ssh용, 포트 22은 Telnet용, 즉 암호화되지 않은 메시지 전송용입니다. 매우 인기 있는 포트 23은 HTTP를 통해 데이터를 전달하는 반면, 포트 80은 HTTP의 보안 버전과 유사한 HTTPS를 통해 암호화된 데이터를 전달합니다.
일부 포트는 TCP와 UDP 전용이며, 일부는 연결이 TCP인지 UDP인지에 따라 다른 작업을 수행합니다. 따라서 공식적으로 TCP 포트 80은 HTTP에 사용되고 비공식적으로 UDP 포트 80은 HTTP에 사용되지만 다른 HTTP 프로토콜인 QUIC에서는 사용됩니다.

따라서 TCP의 포트 번호는 항상 UDP에서와 동일한 작업을 수행하도록 의도된 것은 아닙니다. 이 목록을 외울 필요는 없으며 기억하는 것도 불가능합니다. 하지만 인기 있고 가장 일반적인 포트 번호를 알아야 합니다. 내가 말했듯이 이러한 포트 중 일부는 표준에 설명된 공식적인 목적을 갖고 있고 일부는 Chromium의 경우처럼 비공식적인 목적을 가지고 있습니다.

따라서 이 표에는 일반적인 포트 번호가 모두 나열되어 있으며, 이 번호는 특정 응용 프로그램을 사용할 때 트래픽을 보내고 받는 데 사용됩니다.

이제 우리가 알고 있는 작은 정보를 기반으로 데이터가 네트워크를 통해 어떻게 이동하는지 살펴보겠습니다. 컴퓨터 10.1.1.10이 이 컴퓨터 또는 주소가 30.1.1.10인 이 서버에 연결하려고 한다고 가정해 보겠습니다. 각 장치의 IP 주소 아래에는 MAC 주소가 있습니다. 마지막 4자로만 구성된 MAC 주소의 예를 제시하고 있지만 실제로는 48자로 구성된 12비트 4진수입니다. 각 숫자는 12비트로 구성되므로 48개의 XNUMX진수는 XNUMX비트 숫자를 나타냅니다.

우리가 알고 있듯이 이 장치가 이 서버에 접속하려면 3방향 핸드셰이크의 첫 번째 단계, 즉 SYN 패킷 전송이 먼저 수행되어야 합니다. 이 요청이 이루어지면 컴퓨터 10.1.1.10은 Windows가 동적으로 생성하는 소스 포트 번호를 지정합니다. Windows는 1에서 65,000 사이의 포트 번호를 임의로 선택합니다. 그러나 1부터 1024까지의 범위의 시작 번호는 널리 알려져 있으므로 이 경우 시스템은 25000보다 큰 숫자를 고려하여 임의의 소스 포트(예: 번호 25113)를 생성합니다.

다음으로 시스템은 패킷에 대상 포트를 추가합니다. 이 경우에는 포트 21입니다. 이 FTP 서버에 연결을 시도하는 애플리케이션은 FTP 트래픽을 보내야 한다는 것을 알고 있기 때문입니다.

다음으로 우리 컴퓨터는 "알겠습니다. 내 IP 주소는 10.1.1.10이고 IP 주소 30.1.1.10에 연결해야 합니다."라고 말합니다. 이 두 주소는 모두 패킷에 포함되어 SYN 요청을 형성하며, 이 패킷은 연결이 끝날 때까지 변경되지 않습니다.

이 비디오를 통해 데이터가 네트워크를 통해 어떻게 이동하는지 이해하시기 바랍니다. 요청을 보내는 컴퓨터는 소스 IP 주소와 대상 IP 주소를 볼 때 대상 주소가 해당 로컬 네트워크에 없다는 것을 이해합니다. 나는 이것이 모두 /24 IP 주소라는 것을 잊어버렸습니다. 따라서 /24 IP 주소를 보면 컴퓨터 10.1.1.10과 30.1.1.10이 동일한 네트워크에 있지 않다는 것을 알 수 있습니다. 따라서 요청을 보내는 컴퓨터는 이 네트워크를 떠나려면 라우터 인터페이스 중 하나에 구성된 10.1.1.1 게이트웨이에 연결해야 한다는 것을 이해합니다. 10.1.1.1로 이동해야 한다는 것과 MAC 주소 1111을 알고 있지만 게이트웨이 10.1.1.1의 MAC 주소는 모릅니다. 그는 무엇을 하고 있나요? 네트워크의 모든 장치가 수신하는 브로드캐스트 ARP 요청을 보내지만 IP 주소가 10.1.1.1인 라우터만 이에 응답합니다.

라우터는 AAAA MAC 주소로 응답하고 소스 및 대상 MAC 주소도 모두 이 프레임에 배치됩니다. 프레임이 준비되면 네트워크를 떠나기 전에 오류 감지를 위한 체크섬을 찾는 알고리즘인 CRC 데이터 무결성 검사가 수행됩니다.
순환 중복 CRC는 SYN부터 마지막 ​​MAC 주소까지 전체 프레임이 MD5라는 해싱 알고리즘을 통해 실행되어 해시 값이 생성됨을 의미합니다. 그런 다음 해시 값 또는 MD5 체크섬이 프레임 시작 부분에 배치됩니다.

FCS는 XNUMX바이트 CRC 값인 프레임 검사 시퀀스이기 때문에 FCS/CRC라는 라벨을 붙였습니다. 일부 사람들은 FCS라는 명칭을 사용하고 일부는 CRC라는 명칭을 사용하므로 두 가지 명칭을 모두 포함시켰습니다. 그러나 기본적으로 이는 단지 해시 값일 뿐입니다. 네트워크를 통해 수신된 모든 데이터에 오류가 없는지 확인해야 합니다. 따라서 이 프레임이 라우터에 도달하면 라우터가 가장 먼저 하는 일은 체크섬 자체를 계산하고 이를 수신된 프레임에 포함된 FCS 또는 CRC 값과 비교하는 것입니다. 이렇게 하면 네트워크를 통해 수신된 데이터에 오류가 없는지 확인한 후 프레임에서 체크섬을 제거할 수 있습니다.

다음으로, 라우터는 MAC 주소를 보고 “좋아요, MAC 주소 AAAA는 프레임이 나에게 주소가 지정되었다는 뜻입니다.”라고 말하고 MAC 주소가 포함된 프레임 부분을 삭제합니다.

대상 IP 주소 30.1.1.10을 살펴보면 이 패킷이 자신에게 전달되지 않았으며 라우터를 통해 더 멀리 이동해야 한다는 것을 이해할 것입니다.

이제 라우터는 주소가 30.1.1.10인 네트워크가 어디에 있는지 확인해야 한다고 "생각"합니다. 아직 라우팅의 전체 개념을 다루지는 않았지만 라우터에는 라우팅 테이블이 있다는 것을 알고 있습니다. 이 테이블에는 주소가 30.1.1.0인 네트워크에 대한 항목이 있습니다. 기억하시겠지만 이는 호스트 IP 주소가 아니라 네트워크 식별자입니다. 라우터는 라우터 30.1.1.0를 통과하여 주소 24/20.1.1.2에 도달할 수 있다고 "생각"합니다.

당신은 그가 이것을 어떻게 아는지 물을 수 있습니다. 관리자가 고정 경로를 구성한 경우 라우팅 프로토콜이나 설정을 통해 이를 알 수 있다는 점을 명심하세요. 그러나 어떤 경우에도 이 라우터의 라우팅 테이블에는 올바른 항목이 포함되어 있으므로 이 패킷을 20.1.1.2로 보내야 한다는 것을 알고 있습니다. 라우터가 이미 대상 MAC 주소를 알고 있다고 가정하면 패킷 전달을 계속하겠습니다. 이 주소를 모르면 ARP를 다시 시작하고 라우터의 MAC 주소 20.1.1.2를 수신하며 프레임 전송 프로세스가 다시 계속됩니다.

따라서 MAC 주소를 이미 알고 있다고 가정하면 BBB 소스 MAC 주소와 CCC 대상 MAC 주소를 갖게 됩니다. 라우터는 다시 FCS/CRC를 계산하여 프레임 시작 부분에 배치합니다.

그런 다음 이 프레임을 네트워크를 통해 전송하고 프레임은 라우터 20.1.12에 도달하여 체크섬을 확인하고 데이터가 손상되지 않았는지 확인한 후 FCS/CRC를 삭제합니다. 그런 다음 MAC 주소를 "잘라내고" 대상을 확인하여 30.1.1.10임을 확인합니다. 그는 이 주소가 자신의 인터페이스에 연결되어 있다는 것을 알고 있습니다. 동일한 프레임 형성 과정이 반복됩니다. 라우터는 소스 및 대상 MAC 주소 값을 추가하고, 해싱을 수행하고, 해시를 프레임에 첨부하여 네트워크를 통해 보냅니다.

우리 서버는 자신에게 전달된 SYN 요청을 최종적으로 수신한 후 해시 체크섬을 확인하고, 패킷에 오류가 없으면 해시를 삭제합니다. 그런 다음 그는 MAC 주소를 제거하고 IP 주소를 살펴본 후 이 패킷이 자신을 향한 것임을 깨닫습니다.
그런 다음 OSI 모델의 세 번째 계층과 관련된 IP 주소를 자르고 포트 번호를 확인합니다.

그는 FTP 트래픽을 의미하는 포트 21을 보고 SYN을 보고 누군가가 그와 통신을 시도하고 있음을 이해합니다.

이제 핸드셰이크에 대해 배운 내용을 바탕으로 서버 30.1.1.10은 SYN/ACK 패킷을 생성하여 컴퓨터 10.1.1.10으로 다시 보냅니다. 이 패킷을 수신하면 장치 10.1.1.10은 ACK를 생성하고 이를 SYN 패킷과 동일한 방식으로 네트워크를 통해 전달하며, 서버가 ACK를 수신한 후 연결이 설정됩니다.

당신이 알아야 할 한 가지는 이 모든 일이 XNUMX초 이내에 일어난다는 것입니다. 이것은 매우 빠른 프로세스이므로 모든 것이 명확하도록 속도를 늦추려고 노력했습니다.
이 튜토리얼에서 배운 내용이 도움이 되기를 바랍니다. 질문이 있으시면 다음 주소로 저에게 편지를 보내주세요. [이메일 보호] 또는 이 영상 아래에 질문을 남겨주세요.

다음 강의부터 YouTube에서 가장 흥미로운 질문 3개를 선택하고 각 동영상 끝에서 이를 검토하겠습니다. 이제부터 "주요 질문" 섹션을 마련하여 귀하의 이름과 함께 질문을 게시하고 실시간으로 답변해 드리겠습니다. 나는 이것이 도움이 될 것이라고 생각합니다.

우리와 함께있어 주셔서 감사합니다. 우리 기사가 마음에 드십니까? 더 재미있는 콘텐츠를 보고 싶다면? 주문하거나 친구에게 추천하여 우리를 지원하십시오. 귀사를 위해 당사가 개발한 고유한 보급형 서버 아날로그에서 Habr 사용자를 위한 30% 할인: VPS(KVM) E5-2650 v4(6코어) 10GB DDR4 240GB SSD 1Gbps에 대한 전체 진실 또는 서버 공유 방법은? (RAID1 및 RAID10에서 사용 가능, 최대 24개 코어 및 최대 40GB DDR4).

VPS(KVM) E5-2650 v4(6코어) 10GB DDR4 240GB SSD 1Gbps 여름까지 무료 XNUMX개월 동안 결제하면 주문할 수 있습니다. 여기에.

Dell R730xd가 2배 더 저렴합니까? 여기서 만 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199부터 네덜란드에서! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - 최저 $99! 에 대해 읽다 인프라 공사를 구축하는 방법. 730페니에 5유로 상당의 Dell R2650xd E4-9000 vXNUMX 서버를 사용하는 클래스?

출처 : habr.com