Python网络编程之网络基础

Python网络编程之网络基础

目录

1. 计算机网络发展

计算机通信诞生之初，系统化与标准化未收到重视，不同厂商只出产各自的网络来实现通信，这样就造成了对用户使用计算机网络造成了很大障碍，缺乏灵活性和可扩展性

为解决该问题，ISO（国际标准化组织）制定了一个国际标准OSI（开放式通信系统互联参考模型）共七层.

在七层模型中，每个分层都接受由它下一层所提供的特定服务，并且负责为自己的上一层提供特定的服务，上下层之间进行交互所遵循的约定叫做“接口”，同一层之间的交互所遵循的约定叫做“协议”

协议就是计算机之间通过网络实现通信时事先达成的一种“约定”(交通规则)；这种“约定”使那些由不同厂商的设备，不同CPU及不同操作系统组成的计算机之间，只要遵循相同的协议就可以实现通信

协议可以分很多种，每一种协议都明确界定了它的行为规范：2台计算机之间必须能够支持相同的协议，并且遵循相同的协议进行处理，才能实现相互通信

1.1. OSI七层模型

七层模型，亦称OSI（Open System Interconnection）。参考模型是国际标准化组织（ISO）制定的一个用于计算机或通信系统间互联的标准体系，一般称为OSI参考模型或七层模型。
image

  • 第7层 应用层
    应用层（Application Layer）提供为应用软件而设计的接口，以设置与另一应用软件之间的通信。例如：HTTP、HTTPS、FTP、Telnet、SSH、SMTP、POP3等。

  • 第6层 表示层
    表示层（Presentation Layer）把数据转换为能与接收者的系统格式兼容并适合传输的格式。

    格式有:JPEG、ASCll、EBCDIC、加密格式等

  • 第5层 会话层
    会话层（Session Layer）负责在数据传输中设置和维护计算机网络中两台计算机之间的通信连接。

  • 第4层 传输层
    传输层（Transport Layer）把传输表头（TH）加至数据以形成数据包。传输表头包含了所使用的协议等发送信息。例如:传输控制协议（TCP）等。

    在这一层，数据的单位称为数据段（segment）

    协议有：TCP UDP，数据包一旦离开网卡即进入网络传输层

  • 第3层 网络层
    网络层（Network Layer）决定数据的路径选择和转寄，将网络表头（NH）加至数据包，以形成报文。网络表头包含了网络资料。例如:互联网协议（IP）等。

    在这一层，数据的单位称为数据包（packet）

    协议有：ICMP IGMP IP（IPV4 IPV6）

  • 第2层 数据链路层
    数据链路层（Data Link Layer）负责网络寻址、错误侦测和改错。当表头和表尾被加至数据包时，会形成信息框（Data Frame）。数据链表头（DLH）是包含了物理地址和错误侦测及改错的方法。数据链表尾（DLT）是一串指示数据包末端的字符串。例如以太网、无线局域网（Wi-Fi）和通用分组无线服务（GPRS）等。

    分为两个子层：逻辑链路控制（logical link control，LLC）子层和介质访问控制（Media access control，MAC）子层。

    在这一层，数据的单位称为帧（frame)

    协议有：ARP、RARP、SDLC、HDLC、PPP、STP、帧中继等

  • 第1层 物理层

    物理层（Physical Layer）在局部局域网上传送数据帧（Data Frame），它负责管理电脑通信设备和网络媒体之间的互通。包括了针脚、电压、线缆规范、集线器、中继器、网卡、主机接口卡等。

    在这一层，数据的单位称为比特（bit）

PDU: Protocol Data Unit,协议数据单元是指对等层次之间传递的数据单位

传输层之上的PDU都称为message

1.2. 七层模型传输数据过程

image

2. TCP/IP协议栈

OSI七层为参考模型，但在实际应用中使用的是TCP/IP模型。

Transmission Control Protocol/Internet Protocol 传输控制协议/因特网互联协议
TCP/IP是一个Protocol Stack，包括TCP、IP、UDP、 ICMP、RIP、TELNET、FTP、SMTP、ARP，ssh等许多协议

最早发源于美国国防部（缩写为DoD）的因特网的前身 ARPA网项目，1983年1月1日，TCP/IP取代了旧的网络 控制协议NCP，成为今天的互联网和局域网的基石和标准,由互联网工程任务组负责维护

共定义了四层，和OSI参考模型的分层有对应关系：
image

2.1 TCP/IP和OSI模型的比较

  • 相同点
    • 两者都是以协议栈的概念为基础
    • 协议栈中的协议彼此相互独立
    • 下层对上层提供服务
  • 不同点
    • 层数不同
    • OSI是先有模型，TCP/IP是先有协议，后有模型
    • OSI是国际标准，可用于各种协议栈，TCP/IP是实际标准，只适用于TCP/IP网络

2.2 TCP协议

TCP 是面向连接的、可靠的、基于字节流的传输层通信协议。

  • 面向连接：一定是「一对一」才能连接，不能像 UDP 协议可以一个主机同时向多个主机发送消息，也就是一对多是无法做到的；
  • 可靠的：无论的网络链路中出现了怎样的链路变化，TCP 都可以保证一个报文一定能够到达接收端；
  • 字节流：消息是「没有边界」的，所以无论我们消息有多大都可以进行传输。并且消息是「有序的」，当「前一个」消息没有收到的时候，即使它先收到了后面的字节，那么也不能扔给应用层去处理，同时对「重复」的报文会自动丢弃。

TCP特点

  • 工作在传输层
  • 面向连接协议
  • 全双工协议
  • 半关闭
  • 错误检查
  • 将数据打包成段，排序
  • 确认机制
  • 数据恢复，重传
  • 流量控制，滑动窗口
  • 拥塞控制，慢启动和拥塞避免算法
    TCP 是一个工作在传输层的可靠数据传输的服务，它能确保接收端接收的网络包是无损坏、无间隔、非冗余和按序的
    image
2.2.1 端口

端口: 用来区别同一台电脑上的不同应用程序,范围：0-65535

端口号的范围：

https://zh.wikipedia.org/wiki/TCP/UDP端口列表

端口号的范围是由IANA来管理和分配的

互联网号码分配局（英语：Internet Assigned Numbers Authority，缩写IANA），是一家互联网地址指派机构，管理国际互联网中使用的IP地址、域名和许多其它参数的机构。

IP地址、自治系统成员以及许多顶级和二级域名分配的日常职责由国际互联网注册中心（IR）和地区注册中心承担。IANA是由ICANN管理的。

0~1023 系统端口或特殊端口(管理员使用)，分配给固定的系统应用，分配严格，如ssh:22 ftp:21 http:80,SMTP:25,pop3:110

1024~49151 用户端口或注册端口，分配给程序注册为某应用,分配不严格。如:mysql:3306 oracle:1521

49152-65535:动态或私有端口，客户端随机使用端口。

2.2.2 TCP包头

  • 源端口、目标端口：计算机上的进程要和其他进程通信是要通过计算机端口的， 而一个计算机端口某个时刻只能被一个进程占用，所以通过指定源端口和目标 端口，就可以知道是哪两个进程需要通信。源端口、目标端口是用16位表示的， 可推算计算机的端口个数为2^16个

  • 序列号：表示本报文段所发送数据的第一个字节的编号。在TCP连接中所传送的 字节流的每一个字节都会按顺序编号。由于序列号由32位表示，所以每2^32个 字节，就会出现序列号回绕，再次从 0 开始，用来解决网络包乱序问题

  • 确认号：表示接收方期望收到发送方下一个报文段的第一个字节数据的编号。 也就是告诉发送方：我希望你（指发送方）下次发送的数据的第一个字节数据 的编号为此确认号，用来解决不丢包的问题

  • 数据偏移：表示TCP报文段的首部长度，共4位，由于TCP首部包含一个长度可 变的选项部分，需要指定这个TCP报文段到底有多长。它指出 TCP 报文段的数 据起始处距离 TCP 报文段的起始处有多远。该字段的单位是32位(即4个字节为 计算单位），4位二进制最大表示15，所以数据偏移也就是TCP首部最大60字节

  • URG：表示本报文段中发送的数据是否包含紧急数据。后面的紧急指针字段（urgent pointer）只有当URG=1时才有效

  • ACK：表示是否前面确认号字段是否有效。只有当ACK=1时，前面的确认号字段才有效。 TCP规定，除了最初建立连接时的 SYN 包之外，ACK必须为1,带ACK标志的TCP报文段称为确认报文段

  • PSH：提示接收端应用程序应该立即从TCP接收缓冲区中读走数据，为接收后续数据腾出空 间。如果为1，则表示对方应当立即把数据提交给上层应用，而不是缓存起来，如果应用程序 不将接收到的数据读走，就会一直停留在TCP接收缓冲区中

  • RST：如果收到一个RST=1的报文，说明与主机的连接出现了严重错误（如主机崩溃），必须释放连接，然后再重新建立连接。或者说明上次发送给主机的数据有问题，主机拒绝响应， 带RST标志的TCP报文段称为复位报文段 ，表示 TCP 连接中出现异常必须强制断开连接。

  • SYN：在建立连接时使用，用来同步序号。当SYN=1，ACK=0时，表示这是一个请求建立连 接的报文段；当SYN=1，ACK=1时，表示对方同意建立连接。SYN=1，说明这是一个请求 建立连接或同意建立连接的报文。只有在前两次握手中SYN才置为1，带SYN标志的TCP报文段称为同步报文段

  • FIN：表示通知对方本端要关闭连接了，标记数据是否发送完毕。如果FIN=1，即告诉对方： “我的数据已经发送完毕，你可以释放连接了”，带FIN标志的TCP报文段称为结束报文段

  • 窗口大小：表示现在允许对方发送的数据量，也就是告诉对方，从本报文段 的确认号开始允许对方发送的数据量，达到此值，需要ACK确认后才能再继 续传送后面数据，由Window size value * Window size scaling factor （此值在三次握手阶段TCP选项Window scale协商得到）得出此值

  • 校验和：提供额外的可靠性

  • 紧急指针：标记紧急数据在数据字段中的位置

  • 选项部分：其最大长度可根据TCP首部长度进行推算。TCP首部长度用4位表 示，选项部分最长为：(2^4-1)*4-20=40字节

    • 常见选项：
      • 最大报文段长度：Maxium Segment Size，MSS，通常1460字节
      • 窗口扩大：Window Scale
      • 时间戳： Timestamps
    • 最大报文段长度MSS（Maximum Segment Size） 指明自己期望对方发送TCP报文段时那个数据字段的长度。比如：1460字节。数据字段的长度加上TCP首部的长度才等于整个TCP报文段的长度。MSS不宜设的太大也不宜设的太小。若选择太小，极端情况下，TCP报文段只含有1字节数据，在 IP层传输的数据报的开销至少有40字节（包括TCP报文段的首部和IP数据报的首 部）。这样，网络的利用率就不会超过1/41。若TCP报文段非常长，那么在IP层传 输时就有可能要分解成多个短数据报片。在终点要把收到的各个短数据报片装配成 原来的TCP报文段。当传输出错时还要进行重传，这些也都会使开销增大。因此 MSS应尽可能大，只要在IP层传输时不需要再分片就行。在连接建立过程中，双 方都把自己能够支持的MSS写入这一字段。 MSS只出现在SYN报文中。即：MSS 出现在SYN=1的报文段中
      • MTU和MSS值的关系：MTU=MSS+IP Header+TCP Header
      • 通信双方最终的MSS值=较小MTU-IP Header-TCP Header
    • 窗口扩大 为了扩大窗口，由于TCP首部的窗口大小字段长度是16位，所以其表示的最大数是 65535。但是随着时延和带宽比较大的通信产生（如卫星通信），需要更大的窗口 来满足性能和吞吐率，所以产生了这个窗口扩大选项
    • 可以用来计算RTT(往返时间)，发送方发送TCP报文时，把当前的时间值放入时间 戳字段，接收方收到后发送确认报文时，把这个时间戳字段的值复制到确认报文中， 当发送方收到确认报文后即可计算出RTT。也可以用来防止回绕序号PAWS，也可 以说可以用来区分相同序列号的不同报文。因为序列号用32为表示，每2^32个序 列号就会产生回绕，那么使用时间戳字段就很容易区分相同序列号的不同报文
2.2.3 TCP三次握手

image
三次握手的过程

刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态。 进行三次握手：

  • 第一次握手(发送的第一个报文：SYN 报文)：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN，将此序号置于 TCP 首部的「序号」字段中，同时把 SYN 标志位置为 1 ，表示 SYN 报文。接着把这个 SYN 报文发送给服务端，表示向服务端发起连接，该报文不包含应用层数据，之后客户端处于 SYN-SENT 状态。

    首部的同步位SYN=1，初始序号seq=x，SYN=1的报文段不能携带数据，但要消耗掉一个序号。
    image

  • 第二次握手(SYN + ACK 报文)：服务器收到客户端的 SYN 报文之后，会以自己的 SYN 报文作为应答，并且服务端也随机初始化自己的序号ISN,将此序号填入 TCP 首部的「序号」字段中。同时会把客户端的 ISN + 1 作为确认号 的值,放到TCP首部的【确认号】中，表示自己已经收到了客户端的 SYN，此时服务器处于 SYN_RCVD 的状态。

    在确认报文段中SYN=1，ACK=1，确认号ack=x+1，初始序号seq=y。
    image

  • 第三次握手：客户端收到 服务器的SYN 报文之后，再会向服务器发送一个 应答(ACK) 报文，首先该应答报文 的TCP 首部 ACK 标志位置为 1 ，同样把服务器发过来的 ISN 号+ 1 后放入放到TCP首部的【确认号】中，表示已经收到了服务端的 SYN 报文，最后把报文发送给服务端。此时客户端处于 ESTABLISHED 状态。服务器收到 ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。

    确认报文段ACK=1，确认号ack=y+1，序号seq=x+1（初始为seq=x，第二个报文段所以要+1），ACK报文段可以携带数据，不携带数据则不消耗序号。
    image
    从上面的过程可以发现第三次握手是可以携带数据的，前两次握手是不可以携带数据的
    TCP协议之所以可靠主要是它接收数据的时候有反馈机制。

为什么要三次握手？两次或四次可以吗？

TCP是提供了一种可靠、面向连接、字节流、传输层的服务，所以在传输数据前要保证双方的收、发能力是正常的
两次握手只能确定一方的网络没有问题，四次握手浪费资源

2.2.4 TCP四次挥手

image

四次挥手过程

  • 第一次挥手：客户端发送一个 FIN位被置为 1 的报文(FIN报文)，报文中会指定一个序列号。此时客户端处于 FIN_WAIT1 状态。 即发出连接释放报文段（FIN=1，序号seq=u），并停止再发送数据，主动关闭TCP连接，进入FIN_WAIT1（终止等待1）状态，等待服务端的确认。

  • 第二次挥手：服务端收到客户端的 FIN报文 之后，会发送 ACK应答报文，并把客户端的序列号值 +1 作为 ACK 报文的序列号值【确认序号】，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。 即服务端收到连接释放报文段后即发出确认报文段（ACK=1，确认号ack=u+1，序号seq=v），服务端进入CLOSE_WAIT（关闭等待）状态，此时的TCP处于半关闭状态，客户端到服务端的连接释放。客户端收到服务端的确认后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的连接释放报文段。

  • 第三次挥手：服务端也要断开连接，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。 即服务端没有要向客户端发出的数据，服务端发出连接释放报文段（FIN=1，ACK=1，序号seq=w，确认号ack=u+1），服务端进入LAST_ACK（最后确认）状态，等待客户端的确认。

  • 第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值【确认序号】，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。 即客户端收到服务端的连接释放报文段后，对此发出确认报文段（ACK=1，seq=u+1，ack=w+1），客户端进入TIME_WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态

主动关闭连接的，才有 TIME_WAIT 状态

为什么 TIME_WAIT 等待的时间是 2MSL？

MSL 是 Maximum Segment Lifetime，报文最大生存时间，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。因为 TCP 报文基于是 IP 协议的，而 IP 头中有一个 TTL 字段，是 IP 数据报可以经过的最大路由数，每经过一个处理他的路由器此值就减 1，当此值为 0 则数据报将被丢弃，同时发送 ICMP 报文通知源主机。

MSL 与 TTL 的区别： MSL 的单位是时间，而 TTL 是经过路由跳数。所以 MSL 应该要大于等于 TTL 消耗为 0 的时间，以确保报文已被自然消亡。

TIME_WAIT 等待 2 倍的 MSL，比较合理的解释是： 网络中可能存在来自发送方的数据包，当这些发送方的数据包被接收方处理后又会向对方发送响应，所以一来一回需要等待 2 倍的时间。

比如如果被动关闭方没有收到断开连接的最后的 ACK 报文，就会触发超时重发 Fin 报文，另一方接收到 FIN 后，会重发 ACK 给被动关闭方， 一来一去正好 2 个 MSL。

2MSL 的时间是从客户端接收到 FIN 后发送 ACK 开始计时的。如果在 TIME-WAIT 时间内，因为客户端的 ACK 没有传输到服务端，客户端又接收到了服务端重发的 FIN 报文，那么 2MSL 时间将重新计时。

在 Linux 系统里 2MSL 默认是 60 秒，那么一个 MSL 也就是 30 秒。Linux 系统停留在 TIME_WAIT 的时间为固定的 60 秒。

如果要修改 TIME_WAIT 的时间长度，只能修改 Linux 内核代码里 TCP_TIMEWAIT_LEN 的值，并重新编译 Linux 内核。

三次握手和四次挥手的过程中一共有11种状态

  • CLOSED 没有任何连接状态
  • LISTEN 侦听状态，等待来自远方TCP端口的连接请求
  • SYN-SENT 在发送连接请求后，等待对方确认
  • SYN-RECEIVED 在收到和发送一个连接请求后，等待对方确认
  • ESTABLISHED 代表传输连接建立，双方进入数据传送状态
  • FIN-WAIT-1 主动关闭,主机已发送关闭连接请求，等待对方确认
  • FIN-WAIT-2 主动关闭,主机已收到对方关闭传输连接确认，等待对方发送关闭 传输连接请求
  • TIME-WAIT 完成双向传输连接关闭，等待所有分组消失
  • CLOSE-WAIT 被动关闭,收到对方发来的关闭连接请求，并已确认
  • LAST-ACK 被动关闭,等待最后一个关闭传输连接确认，并等待所有分组消失
  • CLOSING 双方同时尝试关闭传输连接，等待对方确认

image
客户端先发送一个FIN给服务端，自己进入了FIN_WAIT_1状态，这时等待接收 服务端的报文，该报文会有三种可能：

  • 只有服务端的ACK
  • 只有服务端的FIN
  • 基于服务端的ACK，又有FIN
  1. 只收到服务器的ACK，客户端会进入FIN_WAIT_2状态，后续当收到服务端 的FIN时，回应发送一个ACK，会进入到TIME_WAIT状态，这个状态会持续 2MSL(TCP报文段在网络中的最大生存时间, RFC 1122标准的建议值是2min). 客户端等待2MSL，是为了当最后一个ACK丢失时，可以再发送一次。因为服务 端在等待超时后会再发送一个FIN给客户端，进而客户端知道ACK已丢失
  2. 只有服务端的FIN时，回应一个ACK给服务端，进入CLOSING状态，然后接 收到服务端的ACK时，进入TIME_WAIT状态
  3. 同时收到服务端的ACK和FIN，直接进入TIME_WAIT状态

客户端的典型状态迁移

客户端通过connect系统调用主动与服务器建立连接connect系统调用首先给服 务器发送一个同步报文段，使连接转移到SYN_SENT状态

此后connect系统调用可能因为如下两个原因失败返回：

  1. 如果connect连接的目标端口不存在（未被任何进程监听），或者该端口仍 被处于TIME_WAIT状态的连接所占用（见后文），则服务器将给客户端发送一 个复位报文段，connect调用失败。
  2. 如果目标端口存在，但connect在超时时间内未收到服务器的确认报文段， 则connect调用失败

connect调用失败将使连接立即返回到初始的CLOSED状态。如果客户端成功收 到服务器的同步报文段和确认，则connect调用成功返回，连接转移至 ESTABLISHED状态

当客户端执行主动关闭时，它将向服务器发送一个结束报文段，同时连接进入 FIN_WAIT_1状态。若此时客户端收到服务器专门用于确认目的的确认报文段， 则连接转移至FIN_WAIT_2状态。当客户端处于FIN_WAIT_2状态时，服务器处 于CLOSE_WAIT状态，这一对状态是可能发生半关闭的状态。此时如果服务器 也关闭连接（发送结束报文段），则客户端将给予确认并进入TIME_WAIT状态

客户端从FIN_WAIT_1状态可能直接进入TIME_WAIT状态（不经过FIN_WAIT_2 状态），前提是处于FIN_WAIT_1状态的服务器直接收到带确认信息的结束报文 段（而不是先收到确认报文段，再收到结束报文段）

处于FIN_WAIT_2状态的客户端需要等待服务器发送结束报文段，才能转移至 TIME_WAIT状态，否则它将一直停留在这个状态。如果不是为了在半关闭状态 下继续接收数据，连接长时间地停留在FIN_WAIT_2状态并无益处。连接停留在 FIN_WAIT_2状态的情况可能发生在：客户端执行半关闭后，未等服务器关闭连 接就强行退出了。此时客户端连接由内核来接管，可称之为孤儿连接（和孤儿 进程类似）

客户端三次握手和四次挥手转换状态

image

服务端三次握手和四次挥手转换状态
image

2.3 UDP协议

UDP 是User Datagram Protocol的简称， 中文名是用户数据报协议，是OSI（Open System Interconnection，开放式系统互联） 参考模型中一种无连接的传输层协议，提供面向事务的简单不可靠信息传送服务,而且 UDP 协议是不分客户端和服务端，只分发送端和接收端

特性

  • 工作在传输层
  • 提供不可靠的网络访问
  • 非面向连接协议
  • 有限的错误检查
  • 传输性能高
  • 无数据恢复特性

image

3. IP协议

IP协议（Internet Protocol，互联网协议），是TCP/IP协议栈中最核心的协议之一，通过IP地址，保证了联网设备的唯一性，实现了网络通信的面向无连接和不可靠的传输功能。
image

  • 版本:占4位,指 IP 协议的版本目前的IP协议版本号为4
  • 首部长度:占4位,可表示的最大数值是15个单位，一个单位为4字节，因此IP 的 首部长度的最大值是60字节 (ip头部一共多长，等于固定部分(20)+可选)
  • 区分服务:占8位,用来获得更好的服务,在旧标准中叫做服务类型,但实际上一直未 被使用过.后改名为区分服务.只有在使用区分服务(DiffServ)时,这个字段才起作 用.一般的情况下不使用
  • 总长度:占16位,指首部和数据之和的长度,单位为字节,因此数据报的最大长度为 65535 字节.总长度必须不超过最大传送单元 MTU
  • 标识:占16位,它是一个计数器,通常，每发送一个报文，该值会加1， 也用于数 据包分片，在同一个包的若干分片中，该值是相同的 (如果一个包的大小大于帧的大小(1500),就会分片，同个包拆分出来的值是相同的)
  • 标志(flag):占3位,目前只有后两位有意义 (标志是一个包还是一个分片的包)
    • DF： Don’t Fragment 中间的一位，只有当 DF=0 时才允许分片
    • MF： More Fragment 最后一位，MF=1表示后面还有分片,MF=0 表示最后 一个分片
  • 片偏移:占12位,指较长的分组在分片后，该分片在原分组中的相对位置.片偏移 以8个字节为偏移单位 (在把一个包拆分后，片偏移指的是第几个包)
  • 生存时间:占8位,记为TTL (Time To Live) 数据报在网络中可通过的路由器数的 最大值,TTL 字段是由发送端初始设置一个 8 bit字段.推荐的初始值由分配数字 RFC 指定,当前值为 64.发送 ICMP 回显应答时经常把 TTL 设为最大值 255
  • 协议:占8位,指出此数据报携带的数据使用何种协议以便目的主机的IP层将数据 部分上交给哪个处理过程, 1表示为 ICMP 协议, 2表示为 IGMP 协议, 6表示为 TCP 协议, 17表示为 UDP 协议 (标识上层协议)
  • 首部检验和:占16位,只检验数据报的首部不检验数据部分.这里不采用 CRC 检验 码而采用简单的计算方法
  • 源地址和目的地址:都各占4字节,分别记录源地址和目的地址
  • 片偏移以8个字节为偏移单位，假定MTU=1500
  • 三个包标识 ID都相同，三个包DF都为0，前两个MF=1，最后一个MF=0

主机到主机数据传输过程

先接连
	先ARP广播拿到对方MAC
	三次握手进行TCP连接
创建连接后再进行数据传输

2.3.1 IP地址

  • 它们可唯一标识 IP 网络中的每台设备
  • 每台主机（计算机、网络设备、外围设备）必须具有唯一的地址
  • IP地址由两部分组成 •
    • 网络ID：
      • 标识网络
      • 每个网段分配一个网络ID
    • 主机 ID：
      • 标识单个主机
      • 由组织分配给各设备

互联网诞生之初，IP 地址显得很充裕，于是计算机科学家们设计了分类地址。

IP 地址分类成了 5 种类型，分别是 A 类、B 类、C 类、D 类、E 类。
image

image

公网IP地址

image

私网IP地址

image

公网IP和私网IP的分配是由IANA组织来管理的.

子网掩码

子网掩码(subnet mask)又叫网络掩码、地址掩码、子网络遮罩，它是一种用来指明一个IP地址的哪些位标识的是主机所在的子网，以及哪些位标识的是主机的位掩码。子网掩码不能单独存在，它必须结合IP地址一起使用。子网掩码只有一个作用，就是将某个IP地址划分成网络地址和主机地址两部分。

posted on 2022-01-11 17:00  Hans_Wang  阅读(278)  评论(0)  编辑  收藏  举报

Powered by: 博客园 Copyright © 2024 Hans_Wang
Powered by .NET 9.0 on Kubernetes
回到顶部