答案：首部校验，但是这个校验机制不能够保证数据传输不出错
TCP协议中规定，TCP的首部字段中有一个字段是校验和，发送方将伪首部、TCP首部、TCP数据使用累加校验和的方式计算出一个数字，然后存放在首部的校验和字段里，接收者收到TCP包后重复这个过程，然后将计算出的校验和和接收到的首部中的校验和比较，如果不一致说明数据再传输过程中出错。
因为是利用累加的方法，所以万一前后两个16比特位的数据前后颠倒就又会出现出错的但是没有检查出来的清空
解决方法：既然TCP自带的校验算法并不靠谱，我们就需要在应用层自己建立一套新的数据校验机制
MD5校验：在发送数据前将数据使用MD5加密，并将MD5摘要一起发送，接收端接收数据后将数据再次用MD5加密，如果得到的摘要和收到的摘要一致说明数据正确。
TCP校验和MD5校验，双管齐下
1）面向字节流：以流的方式传输，缓存区满了就划分为几段进行传输
2）超时重传：发送数据包在一定的时间周期内没有收到相应的ACK，等待一定的时间，超时之后就认为这个数据丢失，就会重新发送
3）应答机制：3次握手和4次挥手
4）滑动窗口：控制发送方发送窗口的大小，控制流量
5）拥塞控制：控制传输上流量
6）校验：防止数据传输过长中发生的错误
TCP设有一个保活计时器
服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置成2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，每隔75分钟发送一次，若一连发送10个探测保温仍然没有反应，服务器就认为客户端除了故障，接着就关闭连接
TCP将每个字节的数据都进行了编号，即为序列号，每一个ACK都带有对应的确认序列号，为了告诉发送方，已经收到了哪些数据，下一次从第几个数据开始发送
主机A发送数据给B之后，可能因为网络拥塞等原因，数据无法到达主机B，B也就没有办法给A确认应答，A在一个特定时间间隔内没收到确认应该就会进行重发，但是A没有收到也有可能是因为ACK丢失了，这种情况下，主机B就会收到重复的数据，这时候就需要用到序列号来去重
最理想的情况下，是找到一个最小的时间，保证“确认应答一定能在这个时间内返回”，但是这个时间的长短，随着网络环境的不同，是由差异的，如果超时时间设的太长，会影响整体的重传效率。如果太短，就又可能会频繁发送重复的包
TCP为了保证在任何环境下，都能保证 较高性能的通信，会动态计算这个最大超时时间
确认应答机制需要对每一个发送的数据段返回一个ACK确认应答，在收到上一个ACK之后才能发送下一个数据段，这个机制有一个很大的缺点，就是性能差，尤其是数据往返时间比较长的时候，于是就考虑能不能一次性发送多个数据------>滑动窗口
窗口指的是无需等待确认应答就可以继续发送数据的最大值
上图的窗口大小就是4000个字节，发送前4个字段的时候，不需要等待ACK就可以直接一个一个发送，收到ACK之后根据ack知道有哪些数据已经确认接收到了，就可以将窗口往下滑动并删除那些收到的数据。操作系统为了维护这个滑动窗口，开辟了缓存区，只有ACK确认应答果的数据，才能从缓存区删掉
1，数据包已经收到，但确认应答ACK丢了—— 这种情况下，部分ACK丢失并无大碍，因为还可以通过后续ACK来确认对方已经收到了哪些数据包（通过后面的ack发送端就知道，前面的其实已经收到了）
2，就是数据包丢失了——当某一段报文丢失之后，发送端会收到重复的确认应答，当发送端连续三次收到了同一个应答之后，就会将接收端需要的重新发送过去
这种机制叫做“高速重发控制”，即快重传
why？因为接收端处理数据的速度是有限的，如果发送端发太快会导致接收端的缓冲区被填满，在这个基础上发送端要是再继续发送，就会导致丢包，进而引起丢包重传等一系列连锁反应。因此TCP支持根据接收端的处理能力，来决定发送端的发送速度，这个机制就叫做流量控制flow control
how？接收端将自己可以接收的缓冲区大小放入TCP首部中的“窗口大小”字段，通过ACK通知发送端 ————
接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置成一个更小的值发送给发送端，发送端接收到这个窗口大小的通知之后就会减慢自己的发送速度；如果接收端缓冲区满了，就会将窗口置为0，这时候发送方不再发送数据，但是定期会发送一个窗口探测数据段，让接收端把窗口大小再告诉发送端
当发送端应用进程产生数据很慢、或接收端应用进程处理接收缓冲区数据很慢，或二者兼而有之；就会使应用进程间传送的报文段很小，特别是有效载荷很小。 极端情况下，有效载荷可能只有1个字节；而传输开销有40字节(20字节的IP头+20字节的TCP头) 这种现象就叫糊涂窗口综合症
如果是发送端引起的糊涂窗口综合症：防止发送端的TCP逐个字节地发送数据，必须强迫发送端TCP手机数据然后用一个更大的数据块来发送，Nagle算法
如果是接收端引起的：就是接收端消耗非常慢——假定接收端的TCP的输入缓存为4000字节。发送端先发送第一个4000字节的数据。接收端将它存储在其缓存中。现在缓存满了。它通知窗口大小为零，这表示发送端必须停止发送数据。接收应用程序从接收端的TCP的输入缓存中读取第一个字节的数据。在入缓存中现在有了1字节的空间。接收端的TCP宣布其窗口大小为1字节，这表示正渴望等待发送数据的发送端的TCP会把这个宣布当作一个好消息，并发送只包括一个字节数据的报文段。这样的过程一直继续下去。一个字节的数据被消耗掉，然后发送只包含一个字节数据的报文段。Clark算法：只要有数据到达就发送确认，但宣布的窗口大小为零，直到或者缓存空间已能放入具有最大长度的报文段，或者缓存空间的一半已经空了/或者 延迟确认：当一个报文段到达时并不立即发送确认。接收端在确认收到的报文段之前一直等待，直到入缓存有足够的空间为止。延迟的确认防止了发送端的TCP滑动其窗口。当发送端的TCP发送完其数据后，它就停下来了。这样就防止了这种症状。
当发送者收到了一个窗口为0的应答，发送者便停止发送，等待接收者的下一个应答。但若接收者窗口不为0的应答在传输过程中丢失，发送者就会一直等待下去，而接收者以为发送者已经收到该应答，就会等待接收新数据，这样双方就会相互等待，从而产生死锁
为了避免流量控制引发的死锁，TCP使用了持续计时器。每当发送者收到一个零窗口的应答后就启动该计时器。时间一到便主动发送报文询问接收者的窗口大小。若接收者仍然返回零窗口，则重置该计时器继续等待；若窗口不为0，则表示应答报文丢失了，此时重置发送窗口后开始发送，这样就避免了死锁的产生。
拥塞窗口cwnd初始化为1个报文段：①慢开始（指数规律增长）
到达一个thresh（16）②拥塞避免（线性规律增长）
网络拥塞了③cwnd又重新变为1，但是新的thresh变成拥塞时的一半，并重新执行慢开始算法，到达thresh又执行拥塞避免算法
什么样时网络拥塞了呢？是超时
当发送方连续收到三个重复确认时（这不是网路拥塞，这就是有个包丢失了），执行快重传将丢失报文进行重传，并把cwnd的大小设为阈值窗口的大小，为的是避免网络拥塞，然后线性增大窗口，这个过程就是快恢复
socket/bind/listen/accept/connect/shutdown/close/send/receive
网络传输中有MTU的概念，也就是网络造一个数据包最大的长度，如果要发送超过这个长度的数据包，就需要分包发送。当调用socket的send发送超过MTU的数据包时，操作系统提供的socket实现会自动将这个数据包分割成几个不超过MTU的数据包发送；
当出现这些情况时，接收端就会发现接收到的数据和发送的数据的次数不一致，这个就是粘包现象
MTU= MSS+TCP层头部长度+IP层头部长度 （MSS是指应用层在一个数据包内最大能传输的字节数，MTU是指IP层在一个数据包内最大能传输的字节数）
当我们传输如文件这种数据时，流式的传输非常适合，凡是当我们传输指令之类的数据结构时，流式模型就有一个问题：无法知道指令的结束。所以粘包问题是必须解决的
解决：
1短连接：发送完一个数据包后就断开TCP连接，这样接收端自然就知道数据结束了。 （效率低）
2长连接——定长结构（理想情况）
3长连接——不定长结构：在每次发送的数据的固定偏移位置处写入数据包的长度
问题：TCP两端A、B建立了连接后，如果一端拔掉网线或者拔掉电源，那么另一端能够收到通知吗？
答案：不会
TCP是一种有连接的协议，但是这个连接并不是指有一条实际的电路，而是一种虚拟的电路。TCP的建立连接和断开连接都是通过发送数据实现的，也就是我们常说的三次握手、四次挥手。如果不发送数据那么是无法断开连接的。
正常情况下，当TCP的一段A调用了SOCKET的close或者进程结束，操作系统就会按照TCP协议发送FIN数据报文，B端收到后就会断开连接。
但是当出现了上文所说的异常情况时：被拔掉网线或者断掉电源，总结起来就是没有机会发出断开的FIN数据报文。那么和A直连的路由设备虽然知道A设备已经断开了，但是路由设备并没有保存连接的状态信息，所以路由设备也就不可能去通知B端A端的断开。而B端没有收到断开的数据报文就会依然保持连接。所以A端拔掉网线或者断掉电源后B端是没办法收到断开连接的通知的。
解决方案：
让B端主动通过这个连接像A端继续发送数据即可
上文说过，A端异常断开后，和A端直接连接的路由器是知道的。当B端发送的数据经过转发后到达这个路由器后，必然最终会返回B端一个目的不可达。此时B端立刻就会知道这条连接其实已经异常断开了。
但是B端不可能知道什么时候会出现这种异常，所以B端必须定时发送数据来检测连接是否异常断开。数据的内容无关紧要，任何数据都能达到这个效果。这个数据就是我们经常在TCP编程中所说的心跳。
TCP协议本身就提供了一种这样的机制来探测对端的存货，TCP系恶意有一个KEEP_ALIVE开关，只要打开这个开关就会定时发送一些数据长度为零的探测心跳包，发送的频率和次数都可以设置
除了使用TCP协议本身的保活开关机制，还可以在应用层主动发送心跳数据包，那么在应用层主动发送心跳数据包的方式和TCP协议本身的保活机制有什么区别呢？
1，应用层的心跳数据包会耗费更多的带宽，因为TCP协议的保活机制发送的是数据长度为零心跳包，而应用层的心跳数据包长度则必然会大于0
2，应用层的心跳数据包可以带一些应用层所需要的数据，而TCP的保活机制对于应用层是透明的，无法利用心跳携带数据
两端都有可能发生异常断开的情况。所以TCP连接的两端必须都向对端发送心跳。
Http连接是一种短连接，是一种无状态的连接。所谓的无状态，是指浏览器每次向服务器发起请求的时候，不是通过一个连接，而是每次都建立一个新的连接。
1，请求消息中多了HOST头域，用来识别虚拟主机，为了实现虚拟的web服务器，实现负载均衡？
2，带宽优化：在请求消息中引入range头域，避免发生断连后要请求所有的包
3，新的状态码100，continue，如果不确定服务器是否能够接收大的实体时，发一个只带头域的请求，看返回的是100还是401-unauthorized）
4，消息传递，引入Chunkedtransfer-coding，将大的实体分成任意大小的数据块，都附上长度，最后用一个0长度的块来作为消息结束的标志）
5，缓存
6，支持长连接（PersistentConnection）和请求的流水线（Pipelining）处理
是一种摘要算法，通过内置的hash算法将信息摘要称为定长的16进制字串
由于TCP是双向的， 两边都要发FIN，服务器关闭socket，用close会将该socket的计数-1，如果引用还是大于0，那么socket端口状态保持不变，如果为0，会将sender缓冲中的数发出去，然后发送FIN，可能在多进程中出现半关闭
用shutdown不考虑描述符的引用计数，直接关闭描述符，到LAST_ACK状态，也可选择中止一个方向的连接，只中止读或者只中止些
如果有多个进程共享一个套接字，close每被调用一次，计数减1，直到计数为0时，也就是所用进程都调用了close，套接字将被释放。
在多进程中如果一个进程调用了shutdown(sfd, SHUT_RDWR)后，其它的进程将无法进行通信。但，如果一个进程close(sfd)将不会影响到其它进程。
半关闭状态的产生：
静态路由和动态路由，静态路由用于局域网，内部网络，动态路由用于大型的交换式路由
RIP：基于距离向量的路由协议，通过计算距离来选择路由的路径
OSPF:基于链路状态型的路由，给每一个路径有一个权重，并计算路径的代价最小值，选择这条路径
EGP:外部网关协议
BGP:一种常见的外部网关协议，一种矢量的路由协议，它通过维护IP路由表或‘前缀’表来实现自治系（AS）之间的可达性
假设A和B在同一个网段，主机A要向主机B发送信息。具体的地址解析过程如下：
1，主机A首先查看自己的ARP表，确定其中是否包含有主机B对应的ARP表项。如果找到了对应的MAC地址，则主机A直接利用ARP表中的MAC地址，对IP数据包进行帧封装，并将数据包发送给主机B
2， 如果主机A在ARP表中找不到对应的MAC地址，则将缓存该数据报文，然后以广播方式发送一个ARP请求报文。ARP请求报文中的发送端IP地址和发送端MAC地址为主机A的IP地址和MAC地址，目标IP地址和目标MAC地址为主机B的IP地址和全0的MAC地址。
3，主机B比较自己的IP地址和ARP请求报文中的目标IP地址，当两者相同时进行如下处理：将ARP请求报文中的发送端（即主机A）的IP地址和MAC地址存入自己的ARP表中。之后以单播方式发送ARP响应报文给主机A，其中包含了自己的MAC地址
4，主机A收到ARP响应报文后，将主机B的MAC地址加入到自己的ARP表中以用于后续报文的转发，同时将IP数据包进行封装后发送出去。
为了提高 IP 数据报交付成功的机会,在网际层使用了网际控制报文协议 ICMP
ICMP允许主机或路由器报告差错情况和提供有关异常情况的报告，ICMP是IP层的协议，ICMP报文作为IP层数据报的数据，加上数据报的首部，组成IP数据报发送出去
ICMP有两种：ICMP差错报文和ICMP询问报文
ICMP 报文的前 4 个字节是统一的格式,共有三个字段:即类型、代码和检验和。接着的 4 个字节的内容与 ICMP 的类型有关。
不应发送 ICMP 差错报告报文的几种情况 ：⭐
-对 ICMP 差错报告报文不再发送 ICMP 差错报告报文。
-对具有多播地址的数据报都不发送 ICMP 差错报告报文
-对具有特殊地址(如127.0.0.0 或 0.0.0.0)的数据报不发送 ICMP 差错报告报文。
-对第一个分片的数据报片的所有后续数据报片都不发送 ICMP 差错报告报文。
UDP ICMP ARP OSPF
过程：
首先进程在应用层发起一个IP的ping请求，传输层接收到请求，将其加上udp的头部，转发到IP层，IP层根据ICMP 协议进行封装，添加源IP和目标IP封装成为数据包，然后转到链路层，链路层接收到数据包，进行封装对应的mac地址，调用ARP协议，查询ARP缓存表，没有找到则广播出去，寻找对应IP的mac地址，这个过程用到了路由的协议OSPF。
所有客户机的IP地址设定都是由DHCP服务器集中管理，并负责处理客户端的DHCP请求，而客户端则会使用从服务器分配下来的IP地址；有三种分配方式：自动分配、动态分配、手动分配
DHCP服务工作流程：
DHCP客户机在启动时，会搜寻网络中是否存在DHCP服务器，如果找到，则给DHCP服务器发送一个请求，DHCP接收到请求后，为DHCP客户机选择TCP/IP配置的参数，并把这些参数发送给客户端。
如果已配置冲突检测设置，则DHCP服务器在将租约中的地址提供给客户机之前会使用Ping测试作用域中每个可用地址的连通性。这可确保提供给客户的每个IP地址都没有被使用手动TCP/IP配置的另一台非DHCP计算机使用。
根据客户端是否第一次登录网络，DHCP的工作形式会有所不同。客户端从DHCP服务器上获得IP地址的所有过程可以分为以下六个步骤：
1，当DHCP客户端第一次登录网络时，计算机发现本机上没有任何IP地址设定，就==广播形式发送DHCP discover==来寻找DHCP服务器，即向255.255.255.255发送特定的广播信息。网络上每一台安装了TCP/IP协议的主机都会接收这个广播信息，但只有DHCP服务器才会做出响应。（客户端发送DHCP Discover
2，在网络中接收到DHCP discover发现信息的DHCP服务器就会做出响应，它从尚未分配的IP地址池中挑选一个分配给DHCP客户机，向DHCP客户机发送一个包含分配的IP地址和其他设置的DHCP offer提供信息（服务器向客户端响应DHCP服务，发送DHCP offer
3，DHCP客户端接受到DHCP offer提供信息之后，选择第一个接收到的提供信息，然后以广播的方式回答一个DHCP request请求信息，该信息包含向它所选定的DHCP服务器请求IP地址的内容。（客户端广播回答DHCP request，接收IP地址
4，当DHCP服务器收到DHCP客户端回答的DHCP request请求信息之后，便向DHCP客户端发送一个包含它所提供的IP地址和其他设置的DHCP ack确认信息，告诉DHCP客户端可以使用它提供的IP地址。然后，DHCP客户机便将其TCP/IP协议与网卡绑定，另外，除了DHCP客户机选中的DHCP服务器外，其他的DHCP服务器将收回曾经提供的IP地址。（IP地址配分确认
5，以后DHCP客户端每次重新登录网络时，就不需要再发送DHCP discover发现信息了，而是直接发送包含前一次所分配的IP地址的DHCP request请求信息。当DHCP服务器收到这一信息后，它会尝试让DHCP客户机继续使用原来的IP地址，并回答一个DHCP ack确认信息。如果此IP地址已无法再分配给原来的DHCP客户机使用时，则DHCP服务器给DHCP客户机回答一个DHCP nack否认信息。当原来的DHCP客户机收到此DHCP nack否认信息后，它就必须重新发送DHCP discover发现信息来请求新的IP地址。（重新登录
DNS，域名系统，将主机名和域名转换为IP地址，是应用层协议，事实上是为其他应用层协议工作的，包括不限于HTTP和SMTP以及FTP，用于将用户提供的主机名解析为ip地址，具体过程：
①用户主机上运行着DNS的客户端，就是我们的PC机或者手机客户端运行着DNS客户端了
②浏览器将接收到的url中抽取出域名字段，就是访问的主机名，比如http://www.baidu.com/，并将这个主机名传送给DNS应用的客户端
③DNS客户机端向网络中的DNS服务器端 发送一份查询报文，报文中包含着要访问的主机名字段（中间包括一些列缓存查询以及分布式DNS集群的工作）
所有DNS请求和回答报文使用的UDP数据报经过端口53发送
④该DNS客户机最终会收到一份回答报文，其中包含有该主机名对应的IP地址
⑤一旦该浏览器收到来自DNS的IP地址，就可以向该IP地址定位的HTTP服务器发起TCP连接
====>在浏览器中输入www . qq .com 域名⭐⭐⭐
1，操作系统会先检查自己本地的hosts文件是否有这个网之映射关系，如果有，就先调用这个IP地址映射，完成域名解析
2，如果hosts里没有这个域名的映射，则查找本地DNS解析器缓存，是否有这个网址映射关系，如果有，直接返回，完成域名解析。
3，如果都没有，就去找TCP/ip参数中设置的首选DNS服务器，叫它本地DNS服务器，此服务器收到查询时，如果要查询的域名，包含在本地配置区域资源中，则返回解析结果给客户机，完成域名解析，此解析具有权威性。
4，如果要查询的域名，不由本地DNS服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个IP地址映射，完成域名解析，此解析不具有权威性
5，如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设置转发器）进行查询：
6，如果未用转发模式，本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后会判断这个域名(.com)是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后，将会联系负责.com域的这台服务器。这台负责.com域的服务器收到请求后，如果自己无法解析，它就会找一个管理.com域的下一级DNS服务器地址(http://qq.com)给本地DNS服务器。当本地DNS服务器收到这个地址后，就会找http://qq.com域服务器，重复上面的动作，进行查询，直至找到www . qq .com主机
7，如果用的是转发模式，此DNS服务器就会把请求转发至上一级DNS服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根DNS或把转请求转至上上级，以此循环。
8，不管是本地DNS服务器用是是转发，还是根提示，最后都是把结果返回给本地DNS服务器，由此DNS服务器再返回给客户机。
从客户端到本地DNS服务器是属于递归查询，而DNS服务器之间的交互查询是迭代查询
主机字节序就是我们平常说的大端和小端模式：不同CPU有不同的字节序类型，这些字节序是指整数在内存中保存的顺序
小端：低位字节排放在内存的低地址端，高位字节排放在内存的高地址端
大端：高位字节排放在内存的低地址端，低位字节排放在内存的高地址端
网络字节序：
4个字节的32 bit值以下面的次序传输：首先是0～7bit，其次8～15bit，然后16～23bit，最后是24~31bit。这种传输次序称作大端字节序
由于TCP/IP首部中所有的二进制整数在网络中传输时都要求以这种次序，因此它又称作网络字节序
