IP/TCP协议知识点

IP/TCP协议

IP/TCP网络模型

基于TCP/IP的模型将协议分成四个层次，它们分别是链路层、网络层、传输层和应用层。

而OSI模型是将协议分成七个层次，他们是对应的。

数据在模型中的封装过程

TCP/IP协议族根据模型的结构，从上往下，将数据层层封装（解封装）。

• 应用层：负责向用户提供应用程序，比如HTTP、FTP、Telnet、DNS、SMTP等。
• 传输层：负责对报文进行分组和重组，并以TCP或UDP协议格式封装报文。
• 网络层：负责路由以及把分组报文发送给目标网络或主机。IP协议在这一层。
• 链路层：负责封装和解封装IP报文，发送和接受ARP/RARP报文等。

以Http协议为例

应用层

Http

HTTP协议是Hyper Text Transfer Protocol（超文本传输协议）的缩写，是用于从万维网（WWW:World Wide Web ）服务器传输超文本到本地浏览器的传送协议。

工作步骤

（1）客户端连接到Web服务器

一个HTTP客户端，通常是浏览器，与Web服务器的HTTP端口（默认为80）建立一个TCP套接字连接。

（2）发送HTTP请求

通过TCP套接字，客户端向Web服务器发送一个文本的请求报文，一个请求报文由请求行、请求头部、空行和请求数据4部分组成。

（3）服务器接受请求并返回HTTP响应

Web服务器解析请求，定位请求资源。服务器将资源复本写到TCP套接字，由客户端读取。一个响应由状态行、响应头部、空行和响应数据4部分组成。

（4）释放连接TCP连接

若connection 模式为close，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接；若connection模式为keepalive，则该连接会保持一段时间，在该时间内可以继续接收请求。

（5）客户端浏览器解析HTML内容

客户端浏览器首先解析状态行，查看表明请求是否成功的状态代码。然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集。客户端浏览器读取响应数据HTML，根据HTML的语法对其进行格式化，并在浏览器窗口中显示。

Http特点

• 简单快速：客户向服务器请求服务时，只需传送请求方法和路径。请求方法常用的有GET、HEAD、POST。每种方法规定了客户与服务器联系的类型不同。由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快。

• 灵活：HTTP允许传输任意类型的数据对象。正在传输的类型由Content-Type加以标记。

• 无连接：无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。

• 无状态：HTTP协议是无状态协议。无状态是指协议对于事务处理没有记忆能力。缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

• 支持B/S及C/S模式。

请求

第一部分：请求行，用来说明请求类型,要访问的资源以及所使用的HTTP版本。

第二部分：请求头部，紧接着请求行之后的部分，用来说明服务器要使用的附加信息

第三部分：空行，请求头部后面的空行是必须的，即使第四部分的请求数据为空，也必须有空行。

第四部分：请求数据也叫主体，可以添加任意的其他数据。

请求方法

HTTP1.0定义了三种请求方法：GET,POST,HEAD。
HTTP1.1新增了五种请求方法：OPTIONS,PUT,DELETE,TRACE,CONNECT。

• GET：请求指定的页面信息，并返回实体主体。
• POST：向指定资源提交数据进行处理请求（例如提交表单或者上传文件）。数据被包含在请求体中。POST请求可能会导致新的资源的建立和/或已有资源的修改。
• HEAD：类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头。
• OPTIONS：允许客户端查看服务器的性能。
• PUT：从客户端向服务器传送的数据取代指定的文档的内容。
• DELETE：请求服务器删除指定的页面。
• CONNECT：HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器。

响应

第一部分：状态行，由HTTP协议版本号，状态码，状态消息三部分组成。

第二部分：消息报头，用来说明客户端要使用的一些附加信息

第三部分：空行，消息报头后面的空行是必须的

第四部分：响应正文，服务器返回给客户端的文本信息。

响应状态码

状态代码有三位数字组成，第一个数字定义了响应的类别，共分五种类别:

• 1xx：指示信息–表示请求已接收，继续处理

• 2xx：成功–表示请求已被成功接收、理解、接受

• 3xx：重定向–要完成请求必须进行更进一步的操作

• 4xx：客户端错误–请求有语法错误或请求无法实现

• 5xx：服务器端错误–服务器未能实现合法的请求

常见状态码：

400：bad　request 客户端请求错误

403：Forbidden 服务器收到请求，但是拒绝提供服务

404：Not found 请求资源不存在

500：Internal Server Error 服务器发生不可预期错误

503：服务器当前不能处理客户端请求

HTTP1.1和HTTP1.0的区别

HTTP1.0每请求一个文档就要建立TCP连接，有几次握手的时间花销，如果一个主页上有很多链接的对象需要依次进行连接，每次连接下载都要消耗这些开销。

HTTP1.1采用持续连接。所谓持续连接就是服务器在发送响应后仍然在一段时间内保持这条连接。使得后序的请求和响应报文都在这条连接上进行。

URI、URL、URN

URI（uniform resource identifier）：统一资源标识符，用来唯一的标识一个资源。

Web上可用的每种资源如HTML文档、图像、视频片段、程序等都是一个来URI来定位的。

URI一般由三部组成：

访问资源的命名机制

存放资源的主机名

资源自身的名称，由路径表示，着重强调于资源。

URL（uniform resource locator）：统一资源定位器，它是一种具体的URI，即URL可以用来标识一个资源，而且还指明了如何locate这个资源。URL是Internet上用来描述信息资源的字符串，主要用在各种WWW客户程序和服务器程序上，特别是著名的Mosaic。采用URL可以用一种统一的格式来描述各种信息资源，包括文件、服务器的地址和目录等。

URL一般由三部组成：

协议(或称为服务方式)

存有该资源的主机IP地址(有时也包括端口号)

主机资源的具体地址。如目录和文件名等

URN（uniform resource name）：统一资源命名，是通过名字来标识资源。

URI是以一种抽象的，高层次概念定义统一资源标识，而URL和URN则是具体的资源标识的方式。URL和URN都是一种URI。笼统地说，每个URL都是URI，但不一定每个URI都是URL。这是因为 URI 还包括一个子类，即统一资源名称 (URN)，它命名资源但不指定如何定位资源。在Java的URI中，一个URI实例可以代表绝对的，也可以是相对的，只要它符合URI的语法规则。而URL类则不仅符合语义，还包含了定位该资源的信息，因此它不能是相对的。
在Java类库中，URI类不包含任何访问资源的方法，它唯一的作用就是解析。相反的是，URL类可以打开一个到达资源的流。

传输层

UDP及其特点

UDP（User Data Protocol，用户数据报协议）：是一个简单的面向数据报的运输层协议。它不提供可靠性，只是把应用程序传给IP层的数据报发送出去，但是不能保证它们能到达目的地。由于UDP在传输数据报前不用再客户和服务器之间建立一个连接，且没有超时重发等机制，所以传输速度很快。

UDP的应用场景：当对网络通讯质量要求不高的时候，要求网络通讯速度能尽量的快，这时就可以使用UDP。

• 面向无连接：首先UDP是不需要建立连接，想发数据就可以开始发送了。并且也只是数据报文的搬运工，不会对数据报文进行任何拆分和拼接操作。也就是说：在发送端，UDP只会给待传数据增加一个UDP头标识下是UDP协议，然后就传递给网络层了。在接收端，UDP 只去除 IP 报文头就传递给应用层，不会任何拼接操作。
• 连接对象个数：UDP不止支持一对一的传输方式，同样支持一对多，多对多，多对一的方式，也就是说 UDP 提供了单播，多播，广播的功能。
• 面向报文：发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付IP层。UDP对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。因此，应用程序必须选择合适大小的报文。
• 首部开销小：传输数据报文时是很高效的，UDP 头部包含了以下几个数据：两个十六位的端口号，分别为源端口（可选字段）和目标端口；整个数据报文的长度；整个数据报文的检验和（IPv4可选字段），该字段用于发现头部信息和数据中的错误。共8个字节。
• 不提供拥塞控制：UDP一直会以恒定的速度发送数据，因此网络出现拥塞不会使源主机的发送速率降低
• 不可靠性：UDP通信不需要建立连接，想发就发，这样的情况肯定不可靠。并且收到什么数据就传递什么数据，也不会备份数据，发送数据也不会关心对方是否已经正确接收到数据了。无拥塞控制的特性导致UDP在网络条件不好的情况下可能会导致丢包。不可靠带来的优点就是，传输速度快，在某些实时性要求高的场景（比如电话会议）就需要使用 UDP。

TCP及其特点

TCP（Transmission Control Protocol，传输控制协议）：提供的是面向连接，可靠的字节流服务。即客户和服务器交换数据前，必须现在双方之间建立一个TCP连接，之后才能传输数据。并且提供超时重发，丢弃重复数据，检验数据，流量控制等功能，保证数据能从一端传到另一端。

TCP的应用场景：当对网络通讯质量有要求的时候，比如：整个数据要准确无误的传递给对方，这往往用于一些要求可靠的应用，比如HTTP、HTTPS、FTP等传输文件的协议，POP、SMTP等邮件传输的协议。

• 面向连接：发送数据之前必须在两端建立连接。建立连接的方法是“三次握手”，这样能建立可靠的连接。建立连接，也是可靠传输的基础。

• 连接对象个数：每条TCP传输连接只能有两个端点，只能进行点对点的数据传输。

• 面向字节流：TCP在不保留报文边界的情况下以字节流方式进行传输。不像UDP一样一个个报文独立地传输。

• 首部开销大：TCP头部包含了以下几个数据：两个十六位的端口号，分别为源端口（可选字段）和目标端口；一个32位序号，表示一次TCP通信过程（从建立连接到断开）过程中某一次传输方向上的字节流的每个字节的编号；一个32位确认号，用作对另一方发送的TCP报文段的响应，其值是收到对方的TCP报文段的序号值＋1；一个4位头部长度，表示TCP头部的长度；一个6位标志位；一个16位窗口大小；一个16位校验和，用来检验TCP报文段在传输过程中是否损坏；一个16位紧急指针，是一个正的偏移量。共20字节。

URG：紧急指针是否有效
ACK：表示确认好是否有效，携带ack标志的报文段也称确认报文段
PSH：提示接收端应用程序应该立即从tcp接受缓冲区中读走数据，为后续接收的数据让出空间
RST：表示要求对方重建连接。带RST标志的tcp报文段也叫复位报文段
SYN：表示建立一个连接，携带SYN的tcp报文段为同步报文段
FIN：表示告知对方本端要关闭连接了。

• 可靠性：面向连接是可靠性的基础，对于可靠传输，判断丢包，误码靠的是TCP的段编号以及确认号。20字节的首部保证了数据传输的可靠。重传机制，通过首部中32位的序号传送到接收端实体的包的按序接收，接收端实体对已成功收到的字节发回一个相应的确认(ACK)，如果发送端实体在合理的往返时延(RTT)内未收到确认，那么对应的数据（假设丢失了）将会被重传。

• 提供拥塞控制：当网络出现拥塞的时候，TCP能够减小向网络注入数据的速率和数量，缓解拥塞。

• TCP提供全双工通信：TCP允许通信双方的应用程序在任何时候都能发送数据，因为TCP连接的两端都设有缓存，用来临时存放双向通信的数据。当然，TCP可以立即发送一个数据段，也可以缓存一段时间以便一次发送更多的数据段（最大的数据段大小取决于MSS）。

TCP和UDP的区别

网络层

IP协议

IP 协议作为通信子网的最高层，提供无连接的数据报传输机制。IP协议是点到点的，核心问题是寻径。它向上层提供统一的IP数据报，使得各种物理帧的差异性对上层协议不复存在。

• 不可靠代表它不能保证ip数据报能成功的到达目的地。
• 无连接 表示ip并不维护任何关于后续数据报的状态信息，每个数据报的处理是相互独立的。普通的ip首部长为20个字节，除非含有选项字段

IP协议报文头

• 4位版本号：指定IP协议的版本，IP4：版本号为4；IP6：版本号为6

• 4位首部长度：表示IP头部长度是多少。每个bit位代表4个字节，IP长度为 length * 4字节，4个bit位表示的最大数为15，因此，IP协议的最大首部长度是15 * 4字节 = 60字节

• 8位服务类型：3位优先权字段(应将弃用)、4位TOS字段、1位保留字段。4位TOS字段分别表示：最小延时，最大吞吐量，最高可靠性，最小成本，这4者相互冲突，只能选择一个，对于ssh/telnet这样的应用程序，最小延时最重要对于ftp这样的应用程序，最大吞吐量最重要

• 16位总长度：IP数据报整体占多少字节

• 16位标识：唯一的标识主机发送的报文，如果IP报文在数据链路层被分片了，那么每一个片里面的这个id字段相同

• 3位标志字段：第一位保留，第二位置为1，标识禁止分片，这时候如果IP报文大于MTU，IP模块就会丢弃报文；第3位表示更多分片，如果分片了的话，最后一个分片置为1，其他都是0，类似于一个结束标记

• 13位分片偏移：是分片相对于原始IP报文开始处的偏移；实际偏移的字节数是这个值 * 8得到，因此，除了最后一个报文之外，其它的报文长度必须是8的整数倍，否则报文不连续

• 8位生存时间：数据包到达目的地的最大报文跳数，一般是64，每次经过一个路由，TTL -= 1，一直减到0还没到达，那么就丢弃了，这个字段主要是为了防止出现路由循环

• 8位协议：表示上层协议的类型

• 16位头部校验和：使用CRC进行校验，来鉴别头部是否损坏

• 32位源地址和32位目标地址：表示发送端和接受端的IP

• 选项字段：不定长，最多40字节

ICMP协议

IP协议并不是一个可靠的协议，它不保证数据被送达，那么，自然的，保证数据送达的工作应该由其他的模块来完成。其中一个重要的模块就是ICMP(网络控制报文)协议。ICMP不是高层协议，而是IP层的协议。

当传送IP数据包发生错误。比如主机不可达，路由不可达等等，ICMP协议将会把错误信息封包，然后传送回给主机。给主机一个处理错误的机会，这 也就是为什么说建立在IP层以上的协议是可能做到安全的原因。

ARP及RARP协议

ARP 是根据IP地址获取MAC地址的一种协议。

ARP（地址解析）协议是一种解析协议，本来主机是完全不知道这个IP对应的是哪个主机的哪个接口，当主机要发送一个IP包的时候，会首先查一下自己的ARP高速缓存（就是一个IP-MAC地址对应表缓存）。

如果查询的IP－MAC值对不存在，那么主机就向网络发送一个ARP协议广播包，这个广播包里面就有待查询的IP地址，而直接收到这份广播的包的所有主机都会查询自己的IP地址，如果收到广播包的某一个主机发现自己符合条件，那么就准备好一个包含自己的MAC地址的ARP包传送给发送ARP广播的主机。

而广播主机拿到ARP包后会更新自己的ARP缓存（就是存放IP-MAC对应表的地方）。发送广播的主机就会用新的ARP缓存数据准备好数据链路层的的数据包发送工作。

RARP协议的工作与此相反。

握手和挥手，以及这两个过程中常见问题：

TCP的三次握手

TCP是面向连接的，无论哪一方向另一方发送数据之前，都必须先在双方之间建立一条连接。在TCP/IP协议中，TCP协议提供可靠的连接服务，连接是通过三次握手进行初始化的。三次握手的目的是同步连接双方的序列号和确认号并交换 TCP窗口大小信息。

第一次握手： 建立连接。客户端发送连接请求报文段，将SYN位置为1，Sequence Number为x；然后，客户端进入SYN_SEND状态，等待服务器的确认；

第二次握手： 服务器收到SYN报文段。服务器收到客户端的SYN报文段，需要对这个SYN报文段进行确认，设置Acknowledgment Number为x+1(Sequence Number+1)；同时，自己自己还要发送SYN请求信息，将SYN位置为1，Sequence Number为y；服务器端将上述所有信息放到一个报文段（即SYN+ACK报文段）中，一并发送给客户端，此时服务器进入SYN_RECV状态；

第三次握手： 客户端收到服务器的SYN+ACK报文段。然后将Acknowledgment Number设置为y+1，向服务器发送ACK报文段，这个报文段发送完毕以后，客户端和服务器端都进入ESTABLISHED状态，完成TCP三次握手。

为什么要三次握手？

为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。

具体例子：“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”

TCP的四次挥手

当客户端和服务器通过三次握手建立了TCP连接以后，当数据传送完毕，要断开TCP连接，也就是四次挥手。

第一次挥手： 主机1（可以使客户端，也可以是服务器端），设置Sequence Number，向主机2发送一个FIN报文段；此时，主机1进入FIN_WAIT_1状态；这表示主机1没有数据要发送给主机2了；

第二次挥手： 主机2收到了主机1发送的FIN报文段，向主机1回一个ACK报文段，Acknowledgment Number为Sequence Number加1；主机1进入FIN_WAIT_2状态；主机2告诉主机1，我“同意”你的关闭请求；

第三次挥手： 主机2向主机1发送FIN报文段，请求关闭连接，同时主机2进入LAST_ACK状态；

第四次挥手： 主机1收到主机2发送的FIN报文段，向主机2发送ACK报文段，然后主机1进入TIME_WAIT状态；主机2收到主机1的ACK报文段以后，就关闭连接；此时，主机1等待2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，主机1也可以关闭连接了。

为什么要四次分手？

TCP协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP是全双工模式，这就意味着，当主机1发出FIN报文段时，只是表示主机1已经没有数据要发送了，主机1告诉主机2，它的数据已经全部发送完毕了；但是，这个时候主机1还是可以接受来自主机2的数据；当主机2返回ACK报文段时，表示它已经知道主机1没有数据发送了，但是主机2还是可以发送数据到主机1的；当主机2也发送了FIN报文段时，这个时候就表示主机2也没有数据要发送了，就会告诉主机1，我也没有数据要发送了，之后彼此就会愉快的中断这次TCP连接。

挥手时为什么要等待2MSL（为什么要有TIME_WAIT状态）？

MSL：报文段最大生存时间，它是任何报文段被丢弃前在网络内的最长时间。

• 保证TCP协议的全双工连接能够可靠关闭

如果主机1直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致主机2没有收到主机1最后回复的ACK。那么主机2就会在超时之后继续发送FIN，此时由于主机1已经CLOSED了，就找不到与重发的FIN对应的连接。所以，主机1不是直接进入CLOSED，而是要保持TIME_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接。

• 保证这次连接的重复数据段从网络中消失

如果主机1直接CLOSED，然后又再向主机2发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但是还是有特殊情况出现：假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达主机2，由于新连接和老连接的端口号是一样的，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL，这样可以保证本次连接的所有数据都从网络中消失。

如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

TCP的流量控制和拥塞控制

流量控制

所谓的流量控制就是让发送方的发送速率不要太快，让接收方来得及接受。利用滑动窗口机制可以很方便的在TCP连接上实现对发送方的流量控制。TCP的窗口单位是字节，不是报文段，发送方的发送窗口不能超过接收方给出的接收窗口的数值。

拥塞控制

所谓拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提，就是网络能承受现有的网络负荷。拥塞问题是一个全局性的问题,涉及到所有的主机、所有的路由器、以及与降低网络传输性能有关的所有因素。

拥塞：在某段时间，对网络中的某一资源的需求超过了该资源所能提供的可用部分，网络的性能就会变化。

拥塞控制和流量控制的差别

拥塞控制所要做就是负载网络能承受现有的网络负荷。拥塞问题是一个全局性的问题，涉及到所有的主机、所有的路由器、以及与降低网络传输性能有关的所有因素。流量控制往往指的是点对点通信量的控制，是个端到端的问题。流量控制所要做的就是控制发送端发送数据的速率，以便使接收端来得及接受。

简单来说，拥塞控制就是控制负载网络需要在现有网络的负荷以内，是控制使用网络与网络负荷之间的平衡。流量控制是控制某个点接收和发送数据的速率。

拥塞控制方法

• 慢开始(Slow-start):发送方先设置cwnd=1，一次发送一个报文段，随后每经过一个传输轮次，cwnd就加倍，其实增长并不慢，以指数形式增长。还要设定一个慢开始门限，当cwnd>门限值，改用拥塞避免算法。

cwnd:拥塞窗口，大小取决于网络的拥塞程度，并且动态地在变化。

• 拥塞避免(Congestion Avoidance):使cwnd按线性规律缓慢增长。当网络发生延时，门限值减半，cwnd重置为1，改用执行慢开始算法。

• 快重传(Fast Restrangsmit):接收方每收到一个失序的报文段后就立即发出重复确认，为的是使发送方及早知道有报文段没有到达对方，而不要等到自己发送数据时才进行捎带确认，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段。失序的报文，例如发送ABCDEFG，其中接收到了ABDEFG，丢失C，那么失序的报文指的是DEFG，接收D时发送一个B的重复确认，E时发送一个B的重复确认，F时再发送一个B的重复确认，这时候重复确认达到3个，发送方立即向接收方再次发送C（在发送G之前）。

  由于发送方尽早重传未被确认的报文段，因此采用快重传后可以使整个网络吞吐量提高约20%。

• 快恢复(Fast Recovery):当发送方连续收到三个重复确认，把慢开始门限减半。与慢开始不同之处是现在不执行慢开始算法（即cwnd现在不设置为1），而是把cwnd值设置为慢开始门限减半后的数值，然后开始执行拥塞避免算法，使cwnd缓慢地线性增大。

可参考博文：

【1】关于HTTP协议

【2】关于TCP/IP，必须知道的十个知识点

【3】TCP流量控制和拥塞控制