关于TCP协议的面筋整理

TCP和UDP的特征及区别、分别适用于那些场景

特征

TCP：面向连接、面向字节流、提供拥塞控制、全双工、一对一通信、首部开销大(固定首部20字节)、提供可靠交付服务
UDP:无连接、面向报文、无拥塞控制、支持一对一、一对多、多对一、多对多的交互模式、头部开销小(仅8字节)、不可靠、时延小、实时性强

TCP报文段、UDP数据报首部相同部分：源端口、目的端口、校验和

区别

TCP是面向连接的；而UDP是无连接的，发送数据前不需要建立连接
面向连接的服务，通信双方在进行通信之前，要先在双方建立起一个完整的可以彼此沟通的通道(TCP三次握手建立连接)，连接双方要为连接分配内核资源。在通信过程中，整个连接的情况一直可以被实时地监控和管理
非面向连接的服务，不需要预先建立一个联络两个通信节点的连接，需要通信的时候，发送节点就可以往网络上发送信息，让信息自主地在网络上去传，一般在传输的过程中不再加以监控。
TCP提供可靠的服务，即通过TCP连接传送的数据无差错、不丢失、不重复且按序到达；UDP只是尽最大努力交付，不保证可靠【可能丢包、不保证有序】
TCP面向字节流；UDP面向报文段
TCP连接只能点对点，而UDP支持一对一、一对多、多对一、多对多的交互模式
TCP数据传输慢；UDP数据传输快
TCP首部开销大；UDP首部开销小
TCP逻辑通信是全双工的可靠通信；UDP是不可靠通信
UDP没有拥塞控制，网络拥塞不会使源主机发送速率降低

应用场景

TCP
适用于要求可靠传输的应用(eg:文件传输)
UDP的应用场景
适用于实时应用(eg:进行视频聊天或者看直播，因为即使几个画面丢失了，对用户来说影响也不是很大)

讲一下OSI七层模型，TCP协议是哪一层？

OSI七层协议
OSI协议就是一个开放的通信系统互联参考模型，也是一个定义的很好的协议规范，它按照功能不同分工不同分为七层:
1.物理层：为上层协议提供传输数据的可靠物理媒介

2.数据链路层：为网络层提供可靠的数据传输。【作用：物理地址寻址、数据的成帧、流量控制、数据的检错、重发】

3.网络层：负责对子网间的数据包进行路由选择。此外，网络层还可以实现拥塞控制、网际互连等功能作【实现两个端系统之间的数据透明传送，具体功能包括寻址和路由选择、连接的建立、保持和终止等】

4.传输层：负责将上层数据分段并提供端到端的、可靠的或不可靠的传输以及端到端的差错控制和流量控制问题。【根据通信子网的特性，最佳的利用网络资源，为两个端系统的会话层之间，提供建立、维护和取消传输连接的功能，负责端到端的数据传输】

5.会话层：管理主机间的会话过程，负责建立、管理、终止进程间的会话

6.表示层：对上层数据/信息进行变换，保证一主机的应用层信息可以被另一主机应用程序理解。数据转换包括：数据的加密、压缩、格式转换

7.应用层：为操作系统/网络应用程序提供访问网络服务的接口

实际上这七层只是人为划分的一个七层模型，目的是为了更容易探讨和理解协议的细节。每一层实现各自的功能和协议，并完成与相邻接口通信，OSI的服务定义详细说明了各层所提供的服务。某一层的服务就是该层及其下各层的一种能力，它通过接口提供给更高一层。各层所提供的服务与这些服务是怎么实现的无关
OSI七层协议是网络的精髓所在

TCP协议在传输层：面向连接、可靠、时延大

OSI七层模型？对应画TCP/IP分层及每层协议、五层协议

讲一下TCP协议

概念：TCP(传输控制协议)是一种面向连接的、可靠的、基于IP的传输层协议。
特点、首部字段：TCP详解

TCP/IP出现阻塞会出现什么状况

连接错误

TCP/IP解决了什么问题

(网络层)解决了计算机之间的通信问题。
主要是不同硬件平台、不同网络产品、不同操作系统之间的兼容性问题，不同类型的计算机网络之间互联互通的问题
流量控制：解决接收端接受速度不如发送端发送快的问题

三次握手、四次挥手的流程、状态、用到的函数？

三次握手

客户端调用connect会首先发送一个SYN分节，它会告诉服务器客户将在连接中发送的数据的初始序列号，进入sys_sent状态
服务端收到这个SYN时，会返回一个ASK，同时发送一个自己的SYN，进入sys_rcvd状态
客户端收到服务端的SYN时，在发送一个ASK。此时TCP连接建立，客户端进入ESTABLISHED状态
服务端收到ASK后也进入ESTABLISHED状态，双方可以开始通信。

大白话解释：
1.A向B申请连接
2.B对A说我准备好了
3.A对B说我也准备好了(A已经进入连接状态，B在听到后进入连接状态)

四次挥手

主动调用close函数的一方为主动关闭端，(客户端)进入FIN_WAIT状态。另一方为被动关闭端。
主动关闭端发送一个FIN分节，被动关闭端收到这个分节，发送一个ASK应答。客户端进入FIN_WAIT2状态，服务端进入CLOSE_WAIT状态
被动关闭方接受到文件结束符的应用程序也会调用close来关闭这个套接字，同时也会发送一个FIN分节。服务端进入LAST_ACK状态
主动关闭方接受到FIN时，会发送一个ACK应答。服务端收到ACK后立即关闭，客户端进入TIME_WAIT状态在2MSL时间后关闭

大白话解释
1.A向B申请断开连接
2.B说知道了，我可以断开连接的时候告诉你
3.B告诉A，我准备好断开连接了
4.A说可以，断开连接(B直接进入关闭状态、A等待2MSL确认不会再有数据报到来后关闭)

为什么进行三次握手，为什么进行第三次？seq为什么是随机值？

第三次握手必要性
在建立连接的过程中，第一次建立连接的请求由于网络阻塞或其他原因服务进程没有及时收到连接请求，延误到某个时刻到达服务进程，此时该连接请求实际上已经失效，如果没有第三次握手，当客户进程收到这个连接请求时，误以为客户进程又发出新的连接请求，于是服务进程像客户进程发出确认报文，同意建立连接，那么只要服务进程发出确认信号，新的连接就会建立；由于该建立连接请求实际上已经失效，客户进程也没有发出新的连接请求，此时客户进程处于CLOSED状态，因此对服务进程的确认信号不会作出相应，通过是否存在第三次握手服务进程能判断客户进程是否发出新的请求，避免误认为连接已建立的这种情况。

序列号为什么是随机值

防止连接失效后SOCKETT被重用使之前残留的包被错误的接收
安全方面：目前对tcp会话的攻击主要分为中间人攻击和注入式攻击。前者是改变通讯双方的通信过程，接管整个tcp会话；后者是不改变通信双方的通信，只是在会话中插入一些伪装IP的TCP包，这就要解决对接收序列号的预测这个技术难题，这个序列号预测也是最大的一个难点，所以从安全的角度来说，tcp序列号初始值越趋近于随机越好，算法越复杂越好。

滑动窗口

滑动窗口协议：一种流量控制方法。可以改善吞吐量的一种，该协议允许发送方在停止并等待确认前可以连续发送多个分组。发送方不必每发一个分组就停下来等待确认，因此该协议可以加速数据的传输。即容许发送方在接收任何应答之前传送附加的包。接收方告诉发送方在某一时刻能送多少包【窗口尺寸】

滑动窗口实质上就是两个指针分别控制滑动窗口的左边界和右边界，并且维护一些计量信息以指示滑动窗口的移动。

TCP滑动窗口可视化：

接收方通告的窗口称为提供的窗口，它覆盖了从第4字节到第9字节的区域，表明接收方已经确认了包括第3字节在内的数据，且通告窗口大小为6。窗口大小是与确认序号相对应的。发送方计算它的可用窗口，该窗口表明多少数据可以立即被发送。
当接收方确认数据后，这个滑动窗口不时地向右移动。窗口两个边沿的相对运动改变窗口的大小。
窗口边沿的移动：

我们使用三个术语描述窗口左右边沿的运动：

称窗口左边沿向右边沿靠近为窗口合拢。这种现象发生在数据被发送和确认时。
当窗口右边沿向右移动时将允许发送更多的数据，我们称之为窗口张开。这种现象发生在另一端的接收进程读取已经确认的数据并释放了TCP的接收缓存时。
当右边沿向左移动时，我们称之为窗口收缩。 Host Requirements RFC强烈建议不要使用这种方式。但TCP必须能够在某一端产生这种情况时进行处理。

根据发送、接收方滑动窗口的大小，可以将滑动窗口协议分为停止等待协议、后退N帧协议、选择重传协议。

停止等待协议
发送方、接收方的滑动窗口大小均为1，每发送一个帧就停止并等待接收方确认，只需要用1位来对帧进行编号：若出现连续相同的帧号，说明发送方对数据帧进行了重传。
后退N帧协议
发送方、接收方的滑动窗口大小均大于等于1，当接收方检测出某一帧出错，要求发送方重传从出错帧后的帧。或者当接收方没有收到某一帧时，没有给发送方发送确认，发送方超时重传从该帧后的帧。注意当帧编号为0~N时，滑动窗口最大为N-1【假设滑动窗口大小为N，当发送方连续发送了N个数据帧，如果接收方收到数据帧后，向发送方发送的确认帧均丢失，则接收方无法判断发送的是新帧还是重传的旧帧。】
选择重传协议
发送方、接收方的滑动窗口大小均大于等于1，与后退N帧协议不同的是，发送方只对超时的、接收方要求重传的数据帧进行重发。帧编号为N时，接收窗口和发送窗口最大为N/2，以保证接收方对新帧和重传的旧帧进行辨认。【假设发送方发送窗口大于N/2，发送方的确认帧丢失，则接收方无法判断接收的下一个同样编号的帧是新帧还是旧帧】

注意：由于窗口的左边沿受另一端发送的确认序号的控制，不可能向左边移动。如果接收到一个指示窗口左边沿向左移动的ACK，则它被认为是一个重复ACK，并被丢弃。
如果左边沿到达右边沿，则称其为一个零窗口，此时发送方不能够发送任何数据。

为什么进行四次挥手，为什么进行第四次？

四次挥手过程中报文段3包含了报文段2中的确认值，因此三次挥手能将报文段3和报文段2合并，但这样合并是有问题的。被动关闭方发送报文段2只是确认主动关闭方发来的结束报文段，但并不代表自身的数据已经传输完毕。即就是当断开连接的时候，一个方向的断开，只是说明该方向数据已传输完毕，而另一方向或许还有数据，所以要等到另一个方向数据也全部传输完成后，才能实现三次握手。但是这个时间不确定，因此会造成主动关闭方的结束报文段长时间未得到响应而进行超时重传等等。造成了不必要的资源浪费甚至更意想不到的问题。