计算机网络——传输层(tcp、三次握手)

一.传输层
1.网络层只把分组发送到目的主机,但是真正通信的并不是主机而是主机中的进程。传输层提供了进程间的逻辑通信,传输层向高层用户屏蔽了下面网络层的核心细节,使应用程序看起来像是在两个传输层实体之间有一条端到端的逻辑通信信道。

在这里插入图片描述

3.TCP首部格式
在这里插入图片描述

4.三次握手
(seq为序号,ack为确认号)
在这里插入图片描述

5.三次握手的原因:为了确保双方的接受和发送是正常的。
举例:为了防止已经失效的连接请求报文又突然传到了服务端。
因为网络传输会有延迟,当客户端发起第一次握手时,如果该请求在网络中延迟滞留,那么客户端就会隔很长一段时间才能收到服务器端发回的连接确认。
客户端在超时重传时,就会重新发起第一次握手请求建立起一条连接,
此时原先滞留在网络中的第一次握手请求恰好到达了服务端,服务端以为要建立连接,
如果没有第三次握手,则服务器可能会建立起两条连接。因为进行两次握手,则服务端在接收到客户端第一次握手的请求后就建立连接,则服务器可能会建立起两条连接(一条为超时重传发起的请求,一条为滞留的请求),但是对于后面的滞留这次连接,客户端的数据已经在前者中发送完毕,并没有新的数据要发送,因此服务端会白白等待,浪费资源。
如果有第三次握手,客户端会忽略服务器之后发送的对滞留连接请求的连接确认(因为可能判断为重传报文,与前面已确认的报文重复了),不进行第三次握手,因此就不会再次打开连接。(客户端对序号、确检验,则滞留的这条请求的序号不对,因此是不会建连接的)。

6.四次挥手
在这里插入图片描述

7.四次挥手的原因:
客户端发送了 FIN 连接释放报文之后,服务器收到了这个报文,就进入了 CLOSE-WAIT 状态(半关闭状态,服务端 能向 客户端 发送数据但是 客户端 不能向 服务端 发送数据)。这个状态是为了让服务器端发送还未传送完毕的数据,传送完毕之后,服务器会发送 FIN 连接释放报文。

客户端的TIME-WAIT状态(等待2MSL)是为了:
a.确保客户端接收到服务端的FIN报文 后发回确认报文,以使服务端进入CLOSED状态。如果服务端没有收到客户端最后的确认报文(在网络中延迟滞留),则会重发FIN报文,而此时如果客户端已经关闭,那么就接受不到服务端的FIN,客户端 等待一段时间就是为了处理这种情况的发生。

b.等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失,使得下一个新的连接不会出现旧的连接请求报文。

如果是三次挥手:
则将第二和第三次挥手合并,但是因为要留出部分时间让服务器传输剩下的数据,因此不能合并。如果要是删除第四次挥手的话,就会遇到上面的问题。

四次挥手可以看成:客户端分别发出FIN、ACK报文,服务端分别发出FIN、ACK报文,总共四次。FIN报文是表示自己没有数据要发送(但不代表不能接接收数据),ACK报文表示自己不再接收数据。因此需要四次挥手来确保双方都不再发送数据、不再接收数据。

8.TCP使用超时重传来实现可靠传输,如果一个已经发送的报文段在超时时间内没有收到确认,那么就重传这个报文段。

9.TCP流量控制:流量控制是为了控制发送方发送速率,保证接收方来得及接收。

10.TCP滑动窗口:
窗口是缓存的一部分,用来暂时存放字节流。发送方和接收方各有一个窗口,接收方通过 TCP 报文段中的窗口字段告诉发送方自己的窗口大小(三次握手时告诉的),发送方根据这个值和其它信息设置自己的窗口大小。

11.TCP拥塞控制:
如果网络出现拥塞,分组将会丢失,此时发送方会继续重传,从而导致网络拥塞程度更高。因此当出现拥塞时,应当控制发送方的速率。这一点和流量控制很像,但是出发点不同。流量控制是为了让接收方能来得及接收,而拥塞控制是为了降低整个网络的拥塞程度。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值