总结:
1 . TCP 向上层提供面向连接的可靠服务 ,UDP 向上层提供无连接不可靠服务。
2. UDP 没有 TCP 传输可靠,但是可以在实时性要求高的地方有所作为。
3. 对数据准确性要求高,速度可以相对较慢的,可以选用TCP。
4. 应用方面UDP实时应用比如视频直播等,TCP可靠传输比如大文件传输。
5. UDP面向报文(只是数据报文的搬运工,不会对数据报文进行任何拆分和拼接操作。),TCP字节流。
6. UDP头部开销小 8字节相比 TCP 的至少20字节要少得多,传输数据报文时是很高效的。
需要说明的:
源端口
目的端口
seq序号: 占4个字节,是本报文段所发送的数据项目组第一个字节的序号。在TCP传送的数据流中,每一个字节都有一个序号。例如,一报文段的序号为300,而且数据共100字节,则下一个报文段的序号就是400。
ack确认序号: 占4字节,是期望收到对方下次发送的数据的第一个字节的序号,也就是期望收到的下一个报文段的首部中的序号;确认序号应该是上次已成功收到数据字节序号+1。
注意:上述两个序号有值有效的前提是标识为1
标识位:
1、URG:当URG=1时,注解此报文应尽快传送,而不要按本来的列队次序来传送。与“紧急指针”字段共同应用,紧急指针指出在本报文段中的紧急数据的最后一个字节的序号,
使接管方可以知道紧急数据共有多长。
2、ACK:只有当ACK=1时,确认序号字段才有效;
3、PSH:当PSH=1时,接收方应该尽快将本报文段立即传送给其应用层。
4、RST:当RST=1时,表示出现连接错误,必须释放连接,然后再重建传输连接。复位比特还用来拒绝一个不法的报文段或拒绝打开一个连接;
5、SYN:SYN=1,ACK=0时表示请求建立一个连接,携带SYN标志的TCP报文段为同步报文段;
6、FIN:发端完成发送任务。
滑动窗口用于流量控制: TCP流量控制主要是针对接收端的处理速度不如发送端发送速度快的问题,消除发送方使接收方缓存溢出的可能性。。可以理解成接收端所能提供的缓冲区大小。字节数起始于确认序号字段指明的值(这个值是接收端正期望接收的字节。
思考1: 重复发送
第一步发送了[33, 43),如果这次发送[35, 45),那中间重叠部分不是发送了两次,所以这里要 是全部重新发送还是只发送接收端没有收到的数据,如果全部发送那么重复
发送的数据接收端怎么处理。
这个下面快速重传会讲
思考2: 滑动窗口是否可是可靠性的保障?
一直传输数据,直到数据发送完成。这么一来就保证数据数据的可靠性,因为如果某数据没有获取到,那么ack永远不会跳过它。与其说是滑动窗口的可靠,不如说是ACK机制的可靠。
检验和覆盖了整个TCP报文段:TCP首部和数据。这是一个强制性的字段,一定是由发端计算和存储,并由收端进行验证。
win=min(cwnd,接受端接收窗口大小)
说明: 发送方取拥塞窗口与滑动窗口的最小值作为发送的上限。
3. TCP拥塞控制的几种方法:慢启动,拥塞避免,快重传和快恢复。
如果,包没有连续到达,就ack最后那个可能被丢了的包,如果发送方连续收到3次相同的ack,就重传。Fast Retransmit的好处是不用等timeout了再重传,而是只是三次相同的ack就重传。
比如:如果发送方发出了1,2,3,4,5份数据,第一份先到送了,于是就ack回2,结果2因为某些原因没收到,3到达了,于是还是ack回2,后面的4和5都到了,但是还是ack回2因为2还是没有收到,于是发送端收到了三个ack=2的确认,知道了2还没有到,于是就马上重转2。然后,接收端收到了2,此时因为3,4,5都收到了,于是ack回6。
主要是为了避免一个问题就是当接收端发现2丢失之后我是否需要死等2,即使我先收到了3,4,5 ,等到超时再发送? 快速重传保证了,到我收到3, 4,5时不需要等2到超时,我就可以直接返回ack=2了,三次之后,发送端会自动重传3。
没啥好说的理解就行
三次握手
客户端视角:
close 情况下,发起Connet,报文标志 syn , 状态变为SYN_SENT ,等待服务端返回ack (syn ack), 进入established, 之后再发ack,这时可以发送数据了(注意这个时候如果发数据可以添加syn)
服务端视角:
close 情况下,listen等待连接,收到连接后syn_recv 之后返回ack, 等待客户端ack到established
四次挥手
客户端视角:
主动请求关闭,发送FIN这个时候客户端不能发数据了,但是服务端可以发,进入FIN_WAIT1, 接收到 ACK ,进入FIN_WAIT2
,等待,服务端发送FIN, 这个时候进入TIME_WAIT(2MSL),并返回ack给服务端
服务端视角:
收到FIN 包, 回复ack ,进入CLOSE_WAIT, 这个时候还是可以发数据,不发了之后 发一个FIN标志的包,表示要关闭了, 进入 LAST_ACK, 收到客户端的ACK之后CLOSE
为什么客户端TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态?
为什么握手不能是两次?
为了防止服务器端开启一些无用的连接增加服务器开销
防止已失效的连接请求报文段突然又传送到了服务端,因而产生错误。
TCP主要提供了
等方法实现了可靠性传输。但是总结其实还是校验和 序列号/确认应答
那怎么解决呢?