TCP基本原理

协议头部详解

IP：

• 版本（Version）字段：占4比特。用来表明IP协议实现的版本号，当前一般为IPv4，即0100
• 报头长度（Internet Header Length，IHL）字段：占4比特。是头部占32比特的数字，包括可选项。普通IP数据报（没有任何选项），该字段的值是5，即160比特=20字节。此字段最大值为60字节。
• 服务类型（Type of Service ，TOS）字段：占8比特。其中前3比特为优先权子字段（Precedence，现已被忽略）。第8比特保留未用。第4至第7比特分别代表延迟、吞吐量、可靠性和花费。当它们取值为1时分别代表要求最小时延、最大吞吐量、最高可靠性和最小费用。这4比特的服务类型中只能置其中1比特为1。可以全为0，若全为0则表示一般服务。服务类型字段声明了数据报被网络系统传输时可以被怎样处理。例如：TELNET协议可能要求有最小的延迟，FTP协议（数据）可能要求有最大吞吐量，SNMP协议可能要求有最高可靠性，NNTP（Network News Transfer Protocol，网络新闻传输协议）可能要求最小费用，而ICMP协议可能无特殊要求（4比特全为0）。实际上，大部分主机会忽略这个字段，但一些动态路由协议如OSPF（Open Shortest Path First Protocol）、IS-IS（Intermediate System to Intermediate System Protocol）可以根据这些字段的值进行路由决策。
• 总长度字段：占16比特。指明整个数据报的长度（以字节为单位）。最大长度为65535字节。
• 标志字段：占16比特。用来唯一地标识主机发送的每一份数据报。通常每发一份报文，它的值会加1。
• 标志位字段：占3比特。标志一份数据报是否要求分段。
• 段偏移字段：占13比特。如果一份数据报要求分段的话，此字段指明该段偏移距原始数据报开始的位置。
• 生存期（TTL：Time to Live）字段：占8比特。用来设置数据报最多可以经过的路由器数。由发送数据的源主机设置，通常为32、64、128等。每经过一个路由器，其值减1，直到0时该数据报被丢弃。
• 协议字段：占8比特。指明IP层所封装的上层协议类型，如ICMP（1）、IGMP（2） 、TCP（6）、UDP（17）等。
• 头部校验和字段：占16比特。内容是根据IP头部计算得到的校验和码。计算方法是：对头部中每个16比特进行二进制反码求和。（和ICMP、IGMP、TCP、UDP不同，IP不对头部后的数据进行校验）。
• 源IP地址、目标IP地址字段：各占32比特。用来标明发送IP数据报文的源主机地址和接收IP报文的目标主机地址。
• 可选项字段：占32比特。用来定义一些任选项：如记录路径、时间戳等。这些选项很少被使用，同时并不是所有主机和路由器都支持这些选项。可选项字段的长度必须是32比特的整数倍，如果不足，必须填充0以达到此长度要求。

TCP

• 源、目标端口号字段：占16比特。TCP协议通过使用"端口"来标识源端和目标端的应用进程。端口号可以使用0到65535之间的任何数字。在收到服务请求时，操作系统动态地为客户端的应用程序分配端口号。在服务器端，每种服务在"众所周知的端口"（Well-Know Port）为用户提供服务。
• 顺序号字段：占32比特。用来标识从TCP源端向TCP目标端发送的数据字节流，它表示在这个报文段中的第一个数据字节。
• 确认号字段：占32比特。只有ACK标志为1时，确认号字段才有效。它包含目标端所期望收到源端的下一个数据字节。
• 头部长度字段：占4比特。给出头部占32比特的数目。没有任何选项字段的TCP头部长度为20字节；最多可以有60字节的TCP头部
• 标志位字段（U、A、P、R、S、F）：占6比特。各比特的含义如下：
  　　◆URG：紧急指针（urgent pointer）有效。
  　　◆ACK：确认序号有效。
  　　◆PSH：接收方应该尽快将这个报文段交给应用层。
  　　◆RST：重建连接
  　　◆SYN：发起一个连接。
  　　◆FIN：释放一个连接。
• 窗口大小字段：占16比特。此字段用来进行流量控制。单位为字节数，这个值是本机期望一次接收的字节数。
• TCP校验和字段：占16比特。对整个TCP报文段，即TCP头部和TCP数据进行校验和计算，并由目标端进行验证。
• 紧急指针字段：占16比特。它是一个偏移量，和序号字段中的值相加表示紧急数据最后一个字节的序号。
• 选项字段：占32比特。可能包括"窗口扩大因子"、"时间戳"等选项

三次握手连接

• 由客户端client发送建立TCP连接的请求，此时TCP报文会随机生成一个seq为a的序列号，并且把SYN字段设置为1，表示建立TCP连接
• 服务器server接受到客户端发来的TCP连接请求，也会在回复的TCP报文中随机生成一个序列号为b，SYN字段也置为1，ack设置为a+1进行回复，以便客户端收到消息时，知道自己发送的TCP请求已经得到验证
• 客户端收到服务器发送来的消息后，将自己的seq+1即a+1，ack设置为b+1，再次回复给服务器。

建立tcp过程中的五种状态

• 建立连接时，客户端发送SYN为1的消息后，进入syn_sent状态
• 服务器收到客户端建立的请求后，发送ack报文后进入syn_RCVD状态
• 客户端收到ack后，发送ack+1确认包后，双发收到之后都进入established状态

四次握手断开

• 由客户端发起TCP断开链接请求，此时seq为A，FIN置为1，表示请求断开连接
• 服务器收到TCP断开请求后，此时seq为B，ack置为A+1，表示对客户端的断开请求已经收到
• 但服务器并不会马上断开TCP连接，它需要将数据信息全部传到客户端后，然后把TCP报文seq为B，FIN置为1，ack置为A+1，发送请求表示服务器可以断开TCP连接了
• 客户端收到请求后，会发送一个seq为A+1，ack=B+1的确认报文，确认断开连接

tcp断开的6种状态

• 客户端向服务器发送FIN报文后，请求断开连接，进入FIN_WAIT1
• 服务器给客户端发送ack后，应为还需等待这次TCP连接上的数据传输全部完成，因此进入CLOSE_WAIT状态
• 客户端收到ack后进入FIN_WAIT2状态，此时连接已经单方面断开
• 直到服务器数据全部传回客户端后，服务器发送FIN为1的断开请求，进入LAST_ack状态
• 客户端收到服务器的断开请求后，马上发送ack回应，进入TIME_WAIT状态，此时会等待2msl的最大报文生存时间
• 等待2msl之后进入closed状态
• 与此同时服务器收到客户端的ack之后也进入closed状态

为啥是建立时是两次握手

• 一句话，主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。
  如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。
  如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。

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

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

转：https://blog.csdn.net/u013469376/article/details/98727263