tcp协议数据解析(TCP格式的数据格式解析)

即使端口处于2MSL状态，使用该选项，仍然能够在该端口建立连接。服务器常会设置该选项，以防服务器重启。如果在TIME_WAIT时间内，收到了对端发送来的数据报（不是重置报文段都行），那么该状态将被破坏，称为时间等待错误。原因是，当收到报文段以后，通常Seq是旧的，所以本端就会发送ACK，对端已经关闭或者是别的连接，就会发送RST，导致TIME_WAIT状态被破坏。但是许多系统规定，TIME_WAIT状态是不对重置报文段做出反应。两端同时发送FIN，两端又同时ACK。又同时进入TIME_WAIT当处于TIME_WAIT的主机崩溃以后，重启，然后需要等待相当与一个MSL的时间才能建立新的连接。这段时间成为静默时间。当一段发现到达的报文段对相关连接（也就是进程，套接字对）而言不正确的时候，TCP就会发送一个重置报文段，从而导致对端的连接快速拆卸（也就是结束吧！）。重置报文段的ACK位必须有，而且ACK的值必须在正确的窗口范围内，这样可以防止被攻击。FIN正常关闭一条连接成为有序释放，通常不会出现丢失数据的情况。重置报文段终止一条连接成为终止释放。重置报文段在任何时候都可以发送，代替FIN来终止连接，且不学校对端ACK终止报文段特性：当该数值设置为0，那么也意味着，不会再连接终止之前为了确保本端缓存中的数据都发送出去而等待。TCP在发送数据时会设置计时器，如果计时器超时认为受到数据确认信息，就会引发相应的超时，或给予计时器的重传操作，计时器超时时成为重传超时（RTO）。TCP累计确认无法返回新的ACK，或者当ACK包含选择确认信息（SACK）时，表明出现书序数据报，空洞。就会引起快速重传。若RTO短与RTT，那么没分都会重传，反之，整个网络利用率就会随之下降。RTT样本：TCP在收到数据后会返回确认信息ACK，该信息中携带一个字节的数据，测量传输该确认需要的时间，该测量结果成为RTT样本。每个连接的RTT军独立计算。如何根据RTT来设置RTO，有如下的方法公式： SRTT=a*SRTT+(1-a)RTT ，a取 0.8-0.9 。当TCP运行在RTT变化较大的网络中，无法取得期望的结果。以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补因为丢失ACK，或者实际RTT显著增长，可能出现伪超时的现象。以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补每个包可以选择各自的传送路径。某些高级路由器的采用多个并行数据链路，不同的处理演示也会导致包的离开顺序和到达顺序不匹配包的失序会造成重传，很近单嘛，前面一个小号的Seq没到达，后面的先到达，那么ACK就会 重复当TCP超时重发是，循序执行重新租宝，发送送一个更大的报文段提高性能，不超过MSS和MTU。出现在每次传送的包较小，又丢包的情况每个交互键通常会生成一个单独的数据报，也就是每个按键是独立传输的。ssh调用一个shell，对客户端输入的字符做出辉县，因此，每个字符生成4个tcp数据段，客户端的交互按键输入，服务器对按键的ACK，服务器生成的辉县，客户端对回显的ACK。通常第二段和第三段合并，成为捎带延时确认。PSH位设置，意味着发送端的缓存为空，也就是没什么可以发送了。许多情况下，TCP并不是对每个到来的包都单独的ACK，利用累计ACK可以确认之前的ACK。累计确认可以允许TCP延时一段时间发送ACK，以便将ACK和相同方向上需要传输的数据结合发。这种捎带传输的方法常用于批量数据传输。不能任意的延迟ACK，会造成重传。同时当失序发生时，必须立刻传送ACK。系统可以设置，一般延时为200-600毫秒。该算法要求，当TCP连接中有在传数据（那些已发送，但是未确认的数据）时，小的报文段就不能被发送，知道所有的数据都受到ACK。并且受到ACK后，TCP收集这些小的数据，整合到一个报文段中发送。这种方法破事TCP遵循等停规程，只有收到所有传送数据的ACK后才能继续发送新数据。该算法的不同之处在于他实现了自时钟控制，ACK返回越快，传输也越快。在相对高延迟的广域网中，更需要减小小报文的数目，该算法使得单位时间内发送的报文数目更少，RTT控制发包速率。该算法减少小包数目的同时，也增大了传输时延，也就是总的发送时间。窗口大小表明本端可用缓存大小，对端传送的数据不应该超过改大小。也表明对端发送的数据的最大大小为TCP头部ACK号和窗口大小字段之和。也就是Seq = ACK+MSSTCP活动的两端都维护一个发送窗口结构和接受窗口结构。TCP以字节为单位维护窗口结构。每个TCP报文段都包含ACK号和窗口通告信息，TCP发送端可以据此调节窗口结构。窗口左边界不能左移。窗口的动作分为，关闭（收到ACK，左边右移），打开（MSS扩大，右边右移），收缩（MSS减小，右边左移）当收到ACK号增大，而MSS不变时窗口向前滑动当当左边界与右边界相等时，成为零窗口，此时发送端不能在发送新的数据，这种情况下，TCP开始探测对端窗口，伺机增大窗口。当接受窗口值变为0是，可以邮箱的组织发送端继续发送，知道窗口大小回复为非0值。当接收端窗口得到可用空间是，就会给发送端传输一个窗口更新，告知器可以继续发送数据，这样的这样的窗口更新通常不包含数据，成为纯ACK，因此不能保证传输的可靠性。如果一端的窗口更新ACK丢失，通信双方就会处于等待状态。为避免这种情况发生。发送端会采用一个持续计时器间歇性的查询接收端，看其窗口是否已经增长。持续计时器会触发窗口探测的传输，强制要求对端返回ACK。窗口探测包包含一个字节数据，采用TCP传输，因此可以避免窗口更新丢失导致的死锁。因为包含一个字节数据Seq改变，接受端必须处理，如果接受就会ACK。窗口大小还是0，那么就会丢弃该报，没有响应。这时候发送端会持续的发送窗口探测包。当接收端通告窗口较小，或者发送端发送的数据较小。这样数据报的有效携带率小，耗费网络资源多。避免方法以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补以后再补

主要特点：面向连接、面向字节流、全双工通信、通信可靠。优缺点：应用场景：要求通信数据可靠时，即 数据要准确无误地传递给对方。如：传输文件：HTTP、HTTPS、FTP等协议；传输邮件：POP、SMTP等协议ps：首部的前 20 个字节固定，后面有 4n 字节根据需要增加。故 TCP首部最小长度 = 20字节（最大60个字节）。TCP报头中的源端口号和目的端口号同IP数据报中的源IP与目的IP唯一确定一条TCP连接。重要字段：客户端与服务器来回共发送三个TCP报文段来建立运输连接，三个TCP报文段分别为：（1）客户端A向服务器B发送的TCP请求报段“SYN=1,seq=x”；（2）服务器B向客户端A发送的TCP确认报文段“SYN=1,ACK=1,seq=y,ack=x+1”；（3）客户端A向服务器B发送的TCP确认报文段“ACK=1,seq=x+1,ack=y+1”。ps：在建立TCP连接之前，客户端和服务器都处于关闭状态（CLOSED）,直到客户端主动打开连接，服务器才被动打开连接（处于监听状态 = LISTEN）,等待客户端的请求。TCP 协议是一个面向连接的、安全可靠的传输层协议，三次握手的机制是为了保证能建立一个安全可靠的连接。通过上述三次握手，双方确认自己与对方的发送与接收是正常的，就建立起一条TCP连接，即可传送应用层数据。ps：因 TCP提供的是全双工通信，故通信双方的应用进程在任何时候都能发送数据；三次握手期间，任何1次未收到对面的回复，则都会重发。为什么两次握手不行呢？结论：防止服务器接收了早已经失效的连接请求报文，服务器同意连接，从而一直等待客户端请求，最终导致形成死锁、浪费资源。ps：SYN洪泛攻击：（具体见下文）为什么不需要四次握手呢？SYN 同步序列编号(Synchronize Sequence Numbers) 是 TCP/IP 建立连接时使用的握手信号。在客户机和服务器之间建立正常的 TCP 网络连接时，客户机首先发出一个 SYN 消息，服务器使用 SYN-ACK 应答表示接收到了这个消息，最后客户机再以 ACK确认序号标志消息响应。这样在客户机和服务器之间才能建立起可靠的 TCP 连接，数据才可以在客户机和服务器之间传递。如何来解决半连接攻击？如何来解决全连接攻击？请注意，现在 TCP 连接还没有释放掉。必须经过时间等待计时器设置的时间 2MSL（MSL：最长报文段寿命）后，客户端才能进入到 CLOSED 状态，然后撤销传输控制块，结束这次 TCP 连接。当然如果服务器一收到 客户端的确认就进入 CLOSED 状态，然后撤销传输控制块。所以在释放连接时，服务器结束 TCP 连接的时间要早于客户端。TCP是全双工的连接，必须两端同时关闭连接，连接才算真正关闭。简言之，客户端发送了 FIN 连接释放报文之后，服务器收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让服务器端发送还未传送完毕的数据，传送完毕之后，服务器才会发送 FIN 连接释放报文，对方确认后就完全关闭了TCP连接。举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。ps：设想这样一个情景：客户端已主动与服务器建立了 TCP 连接。但后来客户端的主机突然发生故障。显然，服务器以后就不能再收到客户端发来的数据。因此，应当有措施使服务器不要再白白等待下去。这就需要使用TCP的保活计时器。基本原理：tcp11种状态及变迁其实基本包含在正常的三次握手和四次挥手中，除开CLOSING。正常的三次握手包括4中状态变迁：服务器打开监听(LISTEN)->客户端先发起SYN主动连接标识->服务器回复SYN及ACK确认->客户端再确认即三次握手TCP连接成功。这里边涉及四种状态及变迁：正常的四次握手包含6种tcp状态变迁，如主动发起关闭方为客户端：客户端发送FIN进入FIN_WAIT1 -> 服务器发送ACK确认并进入CLOSE_WAIT(被动关闭)状态->客户端收到ACK确认后进入FIN_WAIT2状态 -> 服务器再发送FIN进入LAST_ACK状态 -> 客户端收到服务器的FIN后发送ACK确认进入TIME_WAIT状态 -> 服务器收到ACK确认后进入CLOSED状态断开连接 -> 客户端在等待2MSL的时间如果期间没有收到服务器的相关包，则进入CLOSED状态断开连接。CLOSING状态：连接断开期间，一般是客户端发送一个FIN，然后服务器回复一个ACK，然后服务器发送完数据后再回复一个FIN，当客户端和服务器同时接受到FIN时，客户端和服务器处于CLOSING状态，也就是此时双方都正在关闭同一个连接。在进入CLOSING状态后，只要收到了对方对自己发送的FIN的ACK，收到FIN的ACK确认就进入TIME_WAIT状态，因此，如果RTT(Round Trip Time TCP包的往返延时)处在一个可接受的范围内，发出的FIN会很快被ACK从而进入到TIME_WAIT状态，CLOSING状态持续的时间就特别短，因此很难看到这种状态。我们知道网络层，可以实现两个主机之间的通信。但是这并不具体，因为，真正进行通信的实体是在主机中的进程，是一个主机中的一个进程与另外一个主机中的一个进程在交换数据。IP协议虽然能把数据报文送到目的主机，但是并没有交付给主机的具体应用进程。而端到端的通信才应该是应用进程之间的通信。应用场景：UDP协议比TCP协议的效率更高，TCP协议比UDP协议更加安全可靠。下面主要对数据传输出现错误/无应答/堵塞/超时/重复等问题。注意：TCP丢包：TCP是基于不可靠的网路实现可靠传输，肯定会存在丢包问题。如果在通信过程中，发现缺少数据或者丢包，那边么最大的可能性是程序发送过程或者接受过程中出现问题。总结：为了满足TCP协议不丢包，即保证可靠传输，规定如下：注意：TCP丢包有三方面的原因，一是网络的传输质量不好，二是安全策略，三是服务器性能瓶颈先理解2个基础概念：发送窗口、接收窗口工作原理：注意点：关于滑动窗口的知识点：滑动窗口中的数据类型：ARQ解决的问题：出现差错时，让发送方重传差错数据：即 出错重传类型：流量控制和拥塞控制解决的问题：当接收方来不及接收收到的数据时，可通知发送方降低发送数据的效率：即 速度匹配流量控制：注意：拥塞控制：慢开始与拥塞避免：快重传和快恢复：补充：流量控制和拥塞控制的区别什么情况造成TCP粘包和拆包？解决TCP粘包和拆包的方法：传输层无法保证数据的可靠传输，只能通过应用层来实现了。实现的方式可以参照tcp可靠性传输的方式，只是实现不在传输层，实现转移到了应用层。最简单的方式是在应用层模仿传输层TCP的可靠性传输。下面不考虑拥塞处理，可靠UDP的简单设计。https://www.jianshu.com/p/65605622234bhttp://www.open-open.com/lib/view/open1517213611158.htmlhttps://blog.csdn.net/dangzhangjing97/article/details/81008836https://blog.csdn.net/qq_30108237/article/details/107057946https://www.jianshu.com/p/6c73a4585eba

网络层(network layer)是实现互联网的最重要的一层。正是在网络层面上，各个局域网根据IP协议相互连接，最终构成覆盖全球的Internet。更高层的协议，无论是TCP还是UDP，必须通过网络层的IP数据包(datagram)来传递信息。操作系统也会提供该层的socket，从而允许用户直接操作IP包。 IP数据包是符合IP协议的信息(也就是0/1序列)，我们后面简称IP数据包为IP包。IP包分为头部(header)和数据(Data)两部分。数据部分是要传送的信息，头部是为了能够实现传输而附加的信息(这与以太网帧的头部功能相类似,如果对帧感到陌生，可参看 小喇叭 一文)。IP协议可以分为IPv4和IPv6两种。IPv6是改进版本，用于在未来取代IPv4协议。出于本文的目的，我们可以暂时忽略两者的区别，只以IPv4为例。下面是IPv4的格式IPv4包 我们按照4 bytes将整个序列折叠，以便更好的显示与帧类似，IP包的头部也有多个区域。我们将注意力放在红色的发出地(source address)和目的地(destination address)。它们都是IP地址。IPv4的地址为4 bytes的长度(也就是32位)。我们通常将IPv4的地址分为四个十进制的数，每个数的范围为0-255,比如192.0.0.1就是一个IP地址。填写在IP包头部的是该地址的二进制形式。IP地址是全球地址，它可以识别”社区”(局域网)和”房子”(主机)。这是通过将IP地址分类实现的。IP class    From          To                Subnet MaskA           1.0.0.0       126.255.255.255    255.0.0.0B           128.0.0.0     191.255.255.255    255.255.0.0C           192.0.0.0     223.255.255.255    255.255.255.0每个IP地址的32位分为前后两部分，第一部分用来区分局域网，第二个部分用来区分该局域网的主机。子网掩码(Subnet Mask)告诉我们这两部分的分界线，比如255.0.0.0(也就是8个1和24个0)表示前8位用于区分局域网，后24位用于区分主机。由于A、B、C分类是已经规定好的，所以当一个IP地址属于B类范围时，我们就知道它的前16位和后16位分别表示局域网和主机。网络协议概览 中说，IP地址是分配给每个房子(计算机)的“邮编”。但这个说法并不精确。IP地址实际上识别的是网卡(NIC, Network Interface Card)。网卡是计算机的一个硬件，它在接收到网路信息之后，将信息交给计算机(处理器/内存)。当计算机需要发送信息的时候，也要通过网卡发送。一台计算机可以有不只一个网卡，比如笔记本就有一个以太网卡和一个WiFi网卡。计算机在接收或者发送信息的时候，要先决定想要通过哪个网卡。NIC路由器(router)实际上就是一台配备有多个网卡的专用电脑。它让网卡接入到不同的网络中，这样，就构成在 网络协议概览 中所说的邮局。比如下图中位于中间位置的路由器有两个网卡，地址分别为199.165.145.17和199.165.146.3。它们分别接入到两个网络：199.165.145和199.165.146。IP包的传输要通过路由器的接力。每一个主机和路由中都存有一个路由表(routing table)。路由表根据目的地的IP地址，规定了等待发送的IP包所应该走的路线。就好像下图的路标，如果地址是“东京”，那么请转左；如果地址是“悉尼”，那么请向右。A real world routing table比如我们从主机145.17生成发送到146.21的IP包：铺开信纸，写好信的开头(剩下数据部分可以是TCP包，可以是UDP包，也可以是任意乱写的字，我们暂时不关心)，注明目的地IP地址(199.165.146.21)和发出地IP地址(199.165.145.17)。主机145.17随后参照自己的routing table，里面有三行记录：145.17 routing table (Genmask为子网掩码,Iface用于说明使用哪个网卡接口)Destination        Gateway             Genmask             Iface199.165.145.0      0.0.0.0             255.255.255.0       eth00.0.0.0            199.165.145.17      0.0.0.0             eth0这里有两行记录。第一行表示，如果IP目的地是199.165.145.0这个网络的主机，那么只需要自己在eth0上的网卡直接传送(“本地社区”：直接送达)，不需要前往router(Gateway 0.0.0.0 = “本地送信”)。第二行表示所有不符合第一行的IP目的地，都应该送往Gateway 199.165.145.17，也就是中间router接入在eth0的网卡IP地址(邮局在eth0的分支)。我们的IP包目的地为199.165.146.21，不符合第一行，所以按照第二行，发送到中间的router。主机145.17会将IP包放入帧的payload，并在帧的头部写上199.165.145.17对应的MAC地址，这样，就可以按照 以太网与wifi协议 中的方法在局域网中传送了。中间的router在收到IP包之后(实际上是收到以太协议的帧，然后从帧中的payload读取IP包)，提取目的地IP地址，然后对照自己的routing table：Destination        Gateway             Genmask             Iface199.165.145.0      0.0.0.0             255.255.255.0       eth0199.165.146.0      0.0.0.0             255.255.255.0       eth10.0.0.0            199.165.146.8       0.0.0.0             eth1从前两行我们看到，由于router横跨eth0和eth1两个网络，它可以直接通过eth0和eth1上的网卡直接传送IP包。第三行表示，如果是前面两行之外的IP地址，则需要通过eth1，送往199.165.146.8(右边的router)。我们的目的地符合第二行，所以将IP放入一个新的帧中，在帧的头部写上199.165.146.21的MAC地址，直接发往主机146.21。(在Linux下，可以使用$route -n来查看routing table)IP包可以进一步接力，到达更远的主机。IP包从主机出发，根据沿途路由器的routing table指导，在router间接力。IP包最终到达某个router，这个router与目标主机位于一个局域网中，可以直接建立连接层的通信。最后，IP包被送到目标主机。这样一个过程叫做routing(我们就叫IP包接力好了，路由这个词实在是混合了太多的意思)。整个过程中，IP包不断被主机和路由封装入帧(信封)并拆开，然后借助连接层，在局域网的各个NIC之间传送帧。整个过程中，我们的IP包的内容保持完整，没有发生变化。最终的效果是一个IP包从一个主机传送到另一个主机。利用IP包，我们不需要去操心底层(比如连接层)发生了什么。在上面的过程中，我们实际上假设了，每一台主机和路由都能了解局域网内的IP地址和MAC地址的对应关系，这是实现IP包封装(encapsulation)到帧的基本条件。IP地址与MAC地址的对应是通过ARP协议传播到局域网的每个主机和路由。每一台主机或路由中都有一个ARP cache，用以存储局域网内IP地址和MAC地址如何对应。ARP协议(ARP介于连接层和网络层之间，ARP包需要包裹在一个帧中)的工作方式如下：主机会发出一个ARP包，该ARP包中包含有自己的IP地址和MAC地址。通过ARP包，主机以广播的形式询问局域网上所有的主机和路由：我是IP地址xxxx，我的MAC地址是xxxx，有人知道199.165.146.4的MAC地址吗？拥有该IP地址的主机会回复发出请求的主机：哦，我知道，这个IP地址属于我的一个NIC，它的MAC地址是xxxxxx。由于发送ARP请求的主机采取的是广播形式，并附带有自己的IP地址和MAC地址，其他的主机和路由会同时检查自己的ARP cache，如果不符合，则更新自己的ARP cache。这样，经过几次ARP请求之后，ARP cache会达到稳定。如果局域网上设备发生变动，ARP重复上面过程。(在Linux下，可以使用$arp命令来查看ARP的过程。ARP协议只用于IPv4。IPv6使用Neighbor Discovery Protocol来替代ARP的功能。)我们还有另一个假设，就是每个主机和路由上都已经有了合理的routing table。这个routint table描述了网络的拓扑(topology)结构。如果你了解自己的网络连接，可以手写自己主机的routing table。但是，一个路由器可能有多个出口，所以routing table可能会很长。更重要的是，周围连接的其他路由器可能发生变动(比如新增路由器或者路由器坏掉)，我们就需要routing table能及时将交通导向其他的出口。我们需要一种更加智能的探测周围的网络拓扑结构，并自动生成routing table。我们以北京地铁为例子。如果从机场前往朝阳门，那么可以采取2号航站楼->>三元桥->>东直门->>朝阳门。2号航站楼和朝阳门分别是出发和目的主机。而三元桥和东直门为中间的两个router。如果三元桥->>东直门段因为维修停运，我们需要更改三元桥的routing table，从而给前往朝阳门的乘客(IP包)指示：请走如下路线三元桥->>芍药居。然后依照芍药居的routing table前往朝阳门(芍药居->>东直门->>朝阳门)。一种用来生成routing table的协议是RIP(Routing Information Protocol)。它通过距离来决定routing table，所以属于distance-vector protocol。对于RIP来说，所谓的距离是从出发地到目的地途径的路由器数目(hop number)。比如上面从机场到朝阳门，按照2号航站楼->>三元桥->>东直门->>朝阳门路线，途径两个路由器，距离为2。我们最初可以手动生成三元桥的routing table。随后，根据RIP协议，三元桥向周围的路由器和主机广播自己前往各个IP的距离(比如到机场=0，团结湖=0，国贸=1，望京西=1，建国门=2)。收到RIP包的路由器和主机根据RIP包和自己到发送RIP包的主机的距离，算出自己前往各个IP的距离。东直门与三元桥的距离为1。东直门收到三元桥的RIP包(到机场的距离为0)，那么东直门途径三元桥前往机场的距离为1+0=1。如果东直门自己的RIP记录都比这个远(比如东直门->>芍药居->>三元桥->>机场 = 2)。那么东直门更改自己的routing table：前往机场的交通都发往三元桥而不是芍药居。如果东直门自身的RIP记录并不差，那么东直门保持routing table不变。上述过程在各个点不断重复RIP广播/计算距离/更新routing table的过程，最终所有的主机和路由器都能生成最合理的路径(merge)。(RIP的基本逻辑是：如果A距离B为6，而我距离A为1，那么我途径A到B的距离为7)RIP出于技术上的原因(looping hops)，认为距离超过15的IP不可到达。所以RIP更多用于互联网的一部分(比如整个中国电信的网络)。这样一个互联网的部分往往属于同一个ISP或者有同一个管理机构，所以叫做自治系统(AS,autonomous system)。自治系统内部的主机和路由根据通向外部的边界路由器来和其它的自治系统通信。各个边界路由器之间通过BGP(Border Gateway Protocol)来生成自己前往其它AS的routing table，而自治系统内部则参照边界路由器，使用RIP来决定routing table。BGP的基本工作过程与RIP类似，但在考虑距离的同时，也权衡比如政策、连接性能等其他因素，再决定交通的走向(routing table)。我们一开始讲述了IP包根据routing table进行接力的过程。为了顺利实现接力，我们又进一步深入到ARP和RIP/BGP。这三个协议都协助了IP传输。ARP让每台电脑和路由器知道自己局域网内IP地址和MAC地址的对应关系，从而顺利实现IP包到帧的封装。RIP协议可以生成自治系统内部合理的routing table。BGP协议可以生成自治系统外部的routing table。在整个过程中，我们都将注意力放在了IP包大的传输过程中，而故意忽略一些细节。 而上面的IP接力过程适用于IPv6。【TCP/IP详解】系列教程互联网协议入门 1互联网协议入门 2TCP-IP协议详解(1)网络协议概观TCP-IP协议详解(2) 以太网与WiFi协议TCP-IP协议详解(3) IP/ARP/RIP/BGP协议TCP-IP协议详解(4)IPv4与IPv6地址TCP-IP协议详解(5)IP协议详解TCP-IP协议详解(6) ICMP协议TCP-IP协议详解(7) UDP协议TCP-IP协议详解(8) TCP协议与流通信TCP-IP协议详解(9) TCP连接TCP-IP协议详解(10) TCP滑窗管理TCP-IP协议详解(11) TCP重传TCP-IP协议详解(12) TCP堵塞控制TCP-IP协议详解(13) DNS协议TCP-IP协议详解(14) CIDR与NATTCP-IP协议详解(15) HTTP协议概览 图解TCP-IP协议

TCP/IP协议是一个协议集合，HTTP协议，IP协议，TCP协议，DNS协议等都属于TCP/IP协议。 TCP/IP协议是为了保证全球亿万台计算机能准确、无误的通信。TCP/IP中分层是很重要的概念，每层完成不同的功能。分为应用层，传输层，网络层，数据链路层。分层的目的是为了层级之间的功能相对队里，互不影响。TCP/IP通信数据流HTTP是基于TCP/IP协议的应用层协议，它不涉及数据包的传输，主要规定了客户端和服务器端的通信协议，默认端口是80IP协议的作用是将各种数据包准确无误的传递给对方，其中重要的条件是IP地址和MAC地址。由于IP地址是稀有资源，不可能每个人都有一个IP地址，所以我们通常的IP地址都是路由器给我们生成的IP地址，路由器里面会记录我们的MAC地址，而MAC地址是唯一的。IP实现的两个基本功能：寻址和分段寻址功能就是原地址和目标地址之间建立连接，需要使用ARP协议（Address Resolution Protocol），IP协议就是找到一条连接两台电脑的路径，从而完成数据的交互。地址解析协议，ARP协议，是根据IP地址获取物理地址的一个TCP/IP协议。IP间的通信依赖MAC地址。在进行中转时，会利用下一站中转设备的MAC地址来搜索下一个中转目标，这时就会采用ARP协议，根据通讯放的IP地址就可以反查出对应的MAC地址，从而进行精确的定位，完成寻址的功能。分段功能是为了适应不同网络对包的要求，对数据进行重新组装。TCP协议就是将数据包安全的给对方，IP协议是找到对方的详细地址，分工不同，互不冲突。TCP属于传输层，提供可靠的字节流服务。字节流类似于数据切割，为了方便传输，将大块数据分割成以报文段（segment）为单位的数据包进行管理。可靠的传输服务是指，能够把数据准确可靠的传给对方。TCP协议为了更容易的传输大数据才将数据进行分割，而且TCP协议能够确认数据最终是否送达对方。为了确保信息准确无误的送达，TCP采用了三次握手策略（three-way-handshaking）。TCP建立连接时需要三次握手，在关闭连接时还需要四次握手。 这部分占用了http请求过程的中大量时间，在高并发时，可以考虑优化这部分。和HTTP协议一样是处于应用层的服务，提供域名到IP地址之间的解析服务。1、可缓存：get请求能缓存，post请求不能；响应报文的状态码是可缓存的，包括：200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501。2、get是获取资源，post用于传输实体主体。3、参数：get请求的参数在url里面，会被浏览器保存历史记录，post的请求数据在数据包里面，同时因为url只支持ASCII码，因此get的参数如果存在汉字就要先进性编码，post请求支持更多的编码类型且不对数据类型限制；post传输的数据比get的多；url的长度有限制，会影响get请求；4、安全的HTTP方法不会改变服务器状态，也就说是只读的。所以get是安全的，post不是安全的。5、幂等性：get是幂等的，post不是幂等的。6、XMLHttpRequest： 在使用XMLHttpRequest时，post请求发送时，浏览器会先发送header再发送Data；get请求header和data一起发送。XMLHttpRequest 是一个 API，它为客户端提供了在客户端和服务器之间传输数据的功能。它提供了一个通过 URL 来获取数据的简单方式，并且不会使整个页面刷新。这使得网页只更新一部分页面而不会打扰到用户。XMLHttpRequest 在 AJAX 中被大量使用。200 OK，表示从客户端发来的请求在服务器端被正确处理。204 No content，表示请求成功，但是想要报文不包含实体的主体部分。206 Partial Content ，进行范围请求。301 moved permanently 永久性重定向，表示自愿一杯分配了新的URL。302 found 临时性重定向，表示自愿临时被分配了新的URL。303 see other 表示资源存在着另一个URL，应使用GET方法获取资源。和 302 有着相同的功能，但是 303 明确要求客户端应该采用 GET 方法获取资源。注：虽然 HTTP 协议规定 301、302 状态下重定向时不允许把 POST 方法改成 GET 方法，但是大多数浏览器都会在 301、302 和 303 状态下的重定向把 POST 方法改成 GET 方法。304 not modified 表示服务器允许访问资源，但因发生请求未满足条件的情况。307 temporary redirect，临时重定向，和302含义相同。但是 307 要求浏览器不会把重定向请求的 POST 方法改成 GET 方法。400 bad request 请求报文存在语法错误401 unauthorized 表示没有权限403 forbidden 表示对请求资源的访问被服务器拒绝404 not found 表示在服务器上没有找到请求的资源500 internal sever error 表示服务器端在执行请求时错误503 service unavailable 表明服务器暂时处于超负载或正在停机维护，无法处理请求HTTPS是HTTP建立在SSL/TLS安全协议上的。在IOS中，客户端本地会存有CA证书，在HTTPS请求时，会首先向服务器获取公钥，获得公钥后会使用本地的CA证书验证公钥的正确性，然后通过正确的公钥加密信息发送给服务器，服务器会使用私钥解密信息。SSL/TSL握手阶段分为五步：HTTP和HTTPS的对比：HTTP：无状态，协议对客户端没有状态存储；无连接，每次请求都会和服务器重新建立连接；基于请求和响应，由客户端发起，服务端响应；简单快速，灵活；使用明文，请求和响应不会对通信方进行确认，无法保证数据的完整性。 HTTPS:内容加密，采用混合加密技术，中间者无法直接查看明文内容；验证身份，通过证书认真客户端访问的是自己的服务器；保护数据完整性，放置传输的内容被中间人冒充或篡改。

UDP是一个简单的面向数据报的传输层协议:进程的每个输出操作都正好产生一个UDP数据报，并组装成一份待发送的IP数据报。这与面向流字符的协议不同，如TCP，应用程序产生的全体数据与真正发送的单个IP数据报可能没有什么联系。 UDP数据报封装成一份IP数据报的格式如下图:UTP不提供可靠性:它把应用程序传给IP层的数据发送出去，但是并不保证它们能到达目的地。应用程序必须注意IP数据报的长度。如果它超过网络MTU(最大传输单元)，那么就要对IP数据报进行分片。如果需要源端到目的端的每个网络都要进行分片，并不只是发送端主机连接第一个网络才这样做。首部结构如下图:端口号表示发送进程和接受进程，由于IP层已经把IP数据报分配给TCP或UDP（根据IP首部中协议字段值），因此TCP端口号由TCP来查看，而UDP端口号由UDP来查看。TCP端口号与UDP端口号是相互独立的。UDP长度字段指的是UDP首部和UDP数据的字节长度。该字段的最小值为8字节(发送一份0字节的UDP数据报是OK的)。这个UDP长度是有冗余的，IP数据报长度指的是数据报全长，因此UDP数据报长度等于IP数据报长度减去IP首部的长度。UDP校验和覆盖UDP首部和UDP数据。回想IP首部的校验和，它只覆盖IP的首部----并不覆盖IP数据报的任何数据。UDP和TCP在首部都有覆盖它们首部和数据的校验和。UDP校验和是可选的，而TCP的校验和是必需的。尽管U D P检验和的基本计算方法与我们之前第三节中描述的IP首部检验和计算方法相类似（16bit字的二进制反码和），但是它们之间存在不同的地方。首先，UDP数据报的长度可以为奇数字节，但是检验和算法是把若干个16bit字相加。解决方法是必要时在最后增加填充字节0，这只是为了检验和的计算（也就是说，可能增加的填充字节不被传送）。如果发送端没有计算检验和而接收端检测到检验和有差错，那么UDP数据报就要被悄悄地丢弃。不产生任何差错报文（当IP层检测到IP首部检验和有差错时也这样做）。UDP检验和是一个端到端的检验和。它由发送端计算，然后由接收端验证。其目的是为了发现UDP首部和数据在发送端到接收端之间发生的任何改动。物理网络层一般要限制每次发送数据帧的最大长度。任何时候IP层接收到一份要发送的IP数据报时，它要判断向本地哪个接口发送数据(选路)，并查询该接口获得其MTU。IP把MTU与数据报长度进行比较，如果需要则进行分片。分片可以发生在原始发送端主机上，也可以发生在中间路由器上。把一份IP数据报进行分片以后，只有到达目的地才进行重新组装(这里的重新组装与其他网络协议不同，它们要求在下一站就进行重新组装，而不是在最终目的地)。重新组装由目的端的IP层来完成，其目的是使分片和重新组装过程对传输层(TCP和UDP)是透明的。已经分片过得数据报可能会再次进行分片，IP首部中包含的数据为分片和重新组装提供了足够的信息。对于发送端发送的每份IP数据报来说，其标识字段都包含一个唯一值。该值在数据报分片时被复制到每个片中。标志字段其中一个比特来表示"更多的片"。除了最后一片外，其他每个组成数据报的片都要把比特置1。片偏移字段指的是该片偏移原始数据报开始处的位置。另外，当数据报被分片后，每个片的总长度值要改为该片的长度值。最后，标志字段中有一个比特称作“不分片”位。如果将这一比特置1，IP将不对数据报进行分片。相反把数据报丢弃并发送一个ICMP差错报（“需要进行分片但设置了不分片比特”）给起始端。当IP数据报被分片后，每一片都成为一个分组，具有自己的IP首部，并在选择路由时与其他分组独立。这样，当数据报的这些片到达目的端时可能会失序，但是在IP首部中有足够的信息让接收端能正确组装这些数据报片。IP分片有一个问题:丢失掉一片数据也要重新传输整个数据报。原因:IP层没有超时重传机制---由更高层负责超时和重传。当来自TCP报文段的某一片丢失后，TCP超时会重发整个TCP报文段，该报文段对应于一份IP数据报。没有办法重传数据报中的一个数据报片。使用UDP很容易导致IP分片。下图是UDP分片示例:发现ICMP不可达差错的另一种情况是，当路由器收到一份需要分片的数据报，而在IP首部又设置了不分片(DF)的标志比特。如果某个程序需要判断到达目的端的路途中最小MTU是多少----称作路径MTU发现机制，那么这个差错就可以被该程序使用。这个情况下ICMP不可达差错报文格式如下图：如果路由器没有提供这种新的ICMP差错报文格式，那么下一站的MTU就为0。理论上，IP数据报的最大长度是65535字节，这是由IP首部16比特总长度字段所限制的。去除20字节的IP首部和8个字节的UDP首部，UDP数据报中用户数据的最长长度为65507字节。但是，大多数实现所提供的长度比这个最大值小。其中有两个限制因素:1.应用程序可能会受到其程序接口的限制。socket API提供了一个可供应用程序调用的函数，以设置接收和发送缓存的长度。对于UDP socket，这个长度与应用程序可以读写的最大UDP数据报的长度直接相关。2.第二个限制来自于TCP/IP的内核实现。可能存在一些实现特性(或差错)，是IP数据报长度小于65535字节。我们同样可以使用UDP缠上ICMP"源站抑制"差错。当一个系统(路由器或主机)接受数据报的速度比其处理速度快时，可能产生这个差错。当在以太网传播的数据需要经过SLIP链路时，可能产生该差错报文。因为SLIP链路的速度大约只有以太网的千分之一，所以，很容易使其缓存用完。在本例中，应用程序要么没有接收到源站抑制差错信号，要么接收到却将其忽略了。结果是如果采用UDP协议，那么BSD实现通常忽略其接收到的源站抑制报文。其部分原因在于，在接收到源站抑制差错报文时，导致源站抑制的进程可能已经中止了。不处理ICMP源站抑制差错，说明了UDP是一个非可靠的协议，它只控制端到端的流量控制。除非在应用程序中建立一些应答机制，否则发送端并不知道接收端是否收到了这些数据。来自客户的是UDP数据报。IP首部包含源端和目的端IP地址，UDP首部包含了源端和目的端的UDP端口号。当一个应用程序接收到UDP数据报时，操作系统必须告诉它是谁发送了这份消息，即源IP地址和端口号。这个特性允许一个交互UDP服务器对多个客户进行处理。给每个发送请求的客户发回应答。一些应用程序需要知道数据报是发给谁的，即目的地址。这要求操作系统从接收到的UDP数据报中将目的IP地址交给应用程序。大多数UDP服务器是交互服务器，单个服务器进程对单个UDP端口上的所有客户请求进行处理。通常程序所使用的每个UDP端口都与一个有限大小的输入队列向联系。这意味着，来自不同客户的差不多同时到达的请求将有UDP自动排队。接收到UDP数据报以其接收顺序交给应用程序。因此，由于队列溢出导致的UDP数据报的丢失不可避免。应用程序不知道其输入队列什么时候会溢出，只能有UDP对超出数据报进行丢弃处理。同时，不会发挥任何消息告诉客户其数据报被丢弃。大多数UDP服务器在创建UDP端点时都使其本地IP地址具有通配符的特点。这表明进入的UFP数据报如果其目的地为服务端端口，那么任何本地接口均可接收到它。大多数系统允许UDP端点对远端地址进行限制。下面是UDP服务器本身可以创建的三类地址绑定:在所有情况下，lport指的是服务器有名端口号，localIP必须是本地接口的IP地址。表中这三行的排序是UDP模块在判断用哪个端点接收数据报时所采用的顺序。最为确定的地址（第一行）首先被匹配，最不确定的地址（最后一行IP地址带有两个星号）最后进行匹配。当UDP数据报到达的目的IP地址为广播地址或多播地址，而且在目的IP地址和端口号处有多个端点时，就向每个端点传送一份数据报的复制（端点的本地IP地址可以含有星号，它可匹配任何目的IP地址）。但是，如果UDP数据报到达的是一个单播地址，那么只向其中一个端点传送一份数据报的复制。选择哪个端点传送数据取决于各个不同的系统实现。UDP是一个简单协议。它想用户进程提供的服务位于IP层之上，包括端口号和可选的校验和，我们用UDP老检查校验和并观察分片是如何进行的。 当系统接收IP数据报的速率超过这些数据报被处理的速率时，系统可能发送ICMP源站抑制差错报文。使用UDP时很容易产生这样的ICMP差错。