tcp和udp的区别
（基于连接vs无连接）tcp是面向连接的（三次握手；四次挥手）；udp不是面向连接的
（重量级vs轻量级）tcp是一个重量级的协议；udp则是轻量级的协议。一个tcp数据报的报头大小最少20字节，udp数据报的包头固定8个字节
（可靠性）tcp交付保证：如果消息在传输中丢失，那么它将重发；udp没有交付保证，一个数据包在运输过程中可能丢失。
（有序性）消息到达网络的另一端可能是无序的，tcp协议将为你拍好序。Udp不提供任何有序性的保证。
（速度）tcp慢，适合传输大量数据；udp快，适合传输少量数据。
（流量控制和拥塞控制）TCP有流量控制和拥塞控制，udp没有。
tcp面向字节流，udp面向报文
tcp只能单播，不能发送广播和组播；udp可以广播和组播。
Tcp应用：邮件传输 udp应用：qq聊天、qq视频
流量控制和拥塞控制：
流量控制：就是让发送方发送速率不要太快，要让接收方来的及接收。
拥塞控制：防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有一个前提：网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机、路由器，以及与降低网络传输性能有关的所有因素。
确认应答机制（ACK）
TCP将每个字节的数据都进行了编号，即为序列号。
每一个ACK都带有对应的确认序列号，意思是告诉发送者，我已经收到了哪些数据，下一次你从哪里开始发。
超时重传机制
主机A发送数据给B以后，可能因为网络拥堵等原因，数据无法到达主机B;
如果主机A在一个特定时间间隔内没有收到B发来的确认应答，就会进行重发。
但是，主机A未收到主机B发来的确认应答，也可能是因为ACK丢失了：
因此主机B会收到很多重复数据，那么TCP协议需要能够识别出哪些包是重复的包，并且将这些重复的包丢弃掉，这时我们就可以利用前面提到的序列号，就可以很容易做到去重的效果。
那么超时的时间如何确定呢？最理想的情况下，找到一个最小的时间，保证“确认应答一定能在这个时间内返回”，但是这个时间的长短随着网络环境的不同是有差异的。如果超时时间设的太长，会影响整体的重传效率；如果超时时间设的太短，有可能会频繁地发送重复的包。
TCP为了保证无论在何种情况下都能比较高性能的通信，因此会动态计算这个最大超时时间。Linux中，超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。若重发一次之后仍得不到应答，等待2500ms后再进行重传；如果仍得不到应答，等待4500ms进行重传，依次类推，以指数形式递增。累计到一定的重传次数，TCP认为网络或者对端主机出现异常，强制关闭连接。
滑动窗口
刚才我们讨论了确认应答（ACK）机制，对每一个发送的数据段，都要给一个ACK确认应答，收到ACK后再发送下一个数据段。这样做有一个较大的缺点，就是性能较差，尤其是数据往返时间较长的情况下。
既然一收一发的方式性能较低，那么我们可以一次发送多条数据，这样就可以大大的提高性能。这样做的本质其实就是将多个段的等待时间重叠在一起了。
窗口大小指的是无需等待确认应答而可以继续发送的数据的最大值，这个最大值由接收方的接收缓冲区大小决定。上图所示的窗口大小即为4000个字节（四个段）。
窗口大小是如何确定的呢？其实TCP在建立连接时，就已经协商好了窗口大小。
发送前四个段时，不需要等待任何ACK，直接发送。收到第一个ACK后，滑动窗口向后移动，继续发送第五个段的数据，依次类推。
操作系统内核为了维护这个滑动窗口，需要开辟发送缓冲区来记录当前还有哪些数据没有应答；只有确认应答过的数据才能从缓冲区删掉。
窗口越大，则网络的吞吐率就越高。
这里我们来探讨一种情形：
当主机A收到5001的应答，但未收到3001、4001的应答时，我们可以考虑两种情况：
（1）3001、4001的应答较慢，5001的应答较快，所以先到达；
（2）3001、4001的应答丢失了；
这两种情况其实都不影响，因为收到5001的应答，就表示前5000个数据全收到了。
在滑动窗口中，如果出现了丢包，如何进行重传呢？我们还是分两种情况来讨论：
（1）数据报已经抵达，ACK被丢失了；
在这种情况下，部分ACK丢了并不要紧，因为可以通过后续的ACK进行确认，也就是我们上面举得这个例子。
（2）数据包直接丢失了；
当某一段报文段丢失以后，发送端会一直收到1001这样的ACK，就像是在提醒发送端“我想要的是1001”一样。
如果发送端主机连续三次收到了同样一个“1001”这样的应答，就会将对应的数据1001~2000重新发送。
这时接收端收到了1001以后，再次返回的ACK就是7001了。因为2001~7000接收端其实之前就已经收到了，被放到了接收端操作系统内核的接收缓冲区中。
这种机制被称为“高速重发控制”，也称为“快重传”。
快重传其实是超时重传的一种优化。
流量控制
接收端处理数据的速度是有限的，如果发送端发的太快，导致接收端的缓冲区被打满，这时如果发送端继续发送，就会造成丢包问题，继而导致丢包重传等等一系列连锁反应。因此TCP支持根据接收端的处理能力，来决定发送端的发送速度，这个机制就叫做流量控制。
接收端将自己可以接收的缓冲区大小放入TCP首部中的“窗口大小”字段，通过ACK端通知发送端。我们在讨论滑动窗口时就已经了解到，窗口大小字段越大，说明网络的吞吐量就越高。
接收端一旦发现自己的缓冲区快满了，就会将窗口大小设置为一个更小的值通知给发送端。发送端接收到这个窗口以后，就会减慢自己的发送速度。如果接收端缓冲区满了，就会将窗口置为0，这时发送方不再发送数据，但是需要定期发送一个窗口探测数据段，使接收端把窗口大小告诉发送端。
接收端通过TCP首部中的16位窗口字段（存放了窗口大小信息）将窗口大小告诉发送端。
那么问题来了，16位数字最大可以表示的数字为65535，那么TCP窗口最大就是65535字节么？实际上，TCP首部40字节选项中还包含了一个窗口扩大因子M，实际窗口大小是窗口字段的值左移M位。
拥塞控制
虽然TCP拥有滑动窗口，能够高效可靠的传送大量的数据，但是如果在刚开始阶段就发送大量的数据，仍然可能引发问题。因为网络上有很多的计算机，可能当前的网络状态就已经比较拥堵了，在不清楚当前网络状态的情况下，贸然发送大量的数据，很有可能使得网络状态更加拥堵。
为了解决这个问题，TCP引入了慢启动机制，先发少量的数据摸清当前的网络拥堵状态，再决定按照多大的速度传送。
此处我们要引入一个新的概念——拥塞窗口。
发送开始的时候，我们将拥塞窗口的大小定义为1，每次收到一个ACK应答时，拥塞窗口加1。每次发送数据包时，将拥塞窗口和接收端主机反馈的窗口大小作比较，取较小的值作为实际发送的窗口。
像上面这样的拥塞窗口增长速度，是指数级别的。“慢启动”只是指初始时慢，但是增长速度非常快。为了避免增长速度过快，因此不能使拥塞窗口单纯的加倍。此处引入一个叫做慢启动的阈值，当拥塞窗口超过这个阈值的时候，就不再按照指数方式增长，而是按照线性方式增长。
当TCP开始启动的时候，慢启动阈值等于窗口最大值。在每次超时重发的时候，慢启动阈值会变为原来的一半，同时拥塞窗口置回1。
少量的丢包，我们仅仅是触发超时重传，大量的丢包，我们就认为网络拥塞。
当TCP通信开始后，网络吞吐量会逐渐上升，随着网络发生拥堵，吞吐量会立即下降。
所谓的拥塞控制，归根结底是TCP协议想尽可能快的将数据传输给对方，但是又要避免给网络造成太大压力而采取的折中方案。
延迟应答
如果接收数据的主机立即返回ACK应答，此时返回的窗口可能比较小。假设接收端缓冲区为1M，一次收到了500K的数据，若此时立即应答，则返回的窗口大小为500K。但实际上可能处理端处理的速度非常快，几毫秒内就能将数据从缓冲区消费掉。在这种情况下，接收端处理还远未达到自己的极限，即使窗口大小再大一些，也能处理的过来。如果接收端稍微等一会再应答，比如等待几百毫秒再应答，那么此时返回的窗口大小就是1M。
窗口越大，网络吞吐量就越大，传输速率就越高。我们的目标就是在保证网络不拥塞的情况下尽量提高传输效率。
也不是所有的包都可以延迟应答，这是有数量限制和时间限制的。所谓的数量限制，就是每隔N个包就应答一次；所谓的时间限制，就是超过最大延迟时间就应答一次。而具体的数量和超时时间，依操作系统不同也有差异。一般来说N取2，超时时间取 200ms。
捎带应答
在延迟应答的基础上，我们发现，在很多情况下，客户端服务器在应用层也是“一发一收”的，这就意味着客户端给服务器说了“hello”，服务器也会给客户端回一个“hello”。那么此时ACK就可以搭顺风车，和服务器回应的“hello“一起回给客户端
面向字节流
创建一个TCP的socket，同时在内核中创建一个发送缓冲区和一个接收缓冲区。
在调用write时，数据会先写入发送缓冲区中。如果发送的字节数过长，就会被拆分成多个TCP的数据包发出。若发送的字节数太短，就会先在缓冲区里等待，等到缓冲区的长度差不多或者其他合适的时机，再发送出去。
接收数据时，数据也是从网卡驱动程序到达内核的接收缓冲区，然后应用程序可调用read从接收缓冲区拿数据。
另一方面，TCP的一个连接，既有发送缓冲区，又有接收缓冲区，那么对于这样一个连接，我们既可以读数据，也可以写数据，这个概念就叫做“全双工”。
由于缓冲区的存在，TCP程序的读和写不需要一一匹配。例如：在写100个字节的数据时，既可以调用一次write写100个字节，也可以调用100次write，每次写一个字节。同理，read也是如此。
粘包问题
TCP协议是面向字节流的协议，接收方不知道消息的界限，不知道一次提取多少数据，这就造成了粘包问题。我们可以就生活中的一个例子来帮助理解。在热包子新鲜出炉时，我们免不了会看到这种情况：有些包子粘在了一起，必须通过掰扯才能将它们分开。数据也是如此，“粘包问题”中的包，指的是应用层的数据包。
在TCP的协议头里，没有如同UDP一样的“报文长度”的字段，但是有一个序号的字段。站在传输层的角度，TCP是一个一个报文传过来的，按照序号排好序放到缓冲区中；站在应用层的角度，看到的就只是一串连续的字节数据。那么应用程序看到这一连串的字节数据时，就不知道从哪个部分开始，到哪个部分结束才算是一个完整的应用层数据包。
粘包问题出现的原因：
（1）发送端需要等缓冲区满时才发送出去，造成粘包；
（2）接收端不及时的接收缓冲区内的包，造成多个包接收。
避免粘包问题的方法，归根到底，就是要明确两个包之间的边界：
（1）对于定长的包，保证每次都按固定大小读取即可；
（2）对于变长的包，可以在包头的位置约定一个包总长度的字段，从而就知道了包的结束位置；
（3）对于变长的包，还可以在包和包之间使用明确的分隔符，这个分隔符是由程序员自己来定的，只要保证分隔符不和正文冲突即可。
对于UDP协议来说，就不存在“粘包问题”了，因为：
（1）对于UDP，若还没有上层交付数据，UDP的报文长度仍然在。同时，UDP是一个一个将数据交付给应用层的，具有很明显的数据边界；
（2）站在应用层的角度，使用UDP时，要么收到完整的UDP报文，要么不收，不会出现“半个”的情况。
TCP异常情况
进程终止：文件描述符的生命周期随进程，所以进程终止会释放文件描述符，仍然可以发送FIN，和正常关闭没有什么区别。
机器重启：和进程终止的情况相同。
机器掉电或网线断开：接收端认为连接还在，一旦接收端有写入操作，接收端发现连接已经不在了，就会进行reset。即使无写入操作，TCP自己也内置了一个保活定时器，会定期询问对方是否还在，若对方不在，也会将连接释放掉。
另外，应用层的某些协议，也有一些这样的检测机制，例如HTTP长连接中，也会定期检测对方的状态。例如QQ，在QQ掉线之后，也会定期尝试重新连接。
TCP小结
TCP复杂是因为它既要保证可靠性，同时又要尽可能的提高性能。
可靠性：
（1）校验和；
（2）序列号（保证数据的按序到达）；
（3）确认应答；
（4）超时重传；
（5）连接管理；
（6）流量控制；
（7）拥塞控制。
提高性能：
（1）滑动窗口；
（2）快速重传；
（3）延迟应答；
（4）捎带应答。
其他：
定时器：超时重传定时器。保活定时器。TIME_WAIT定时器等。
