233-Linux tcp通信

1.客户端connect开始执行三次握手,客户端close开始执行四次挥手

2.tcp的服务器端和客户端是面试的时候最有可能考的,必须要会

3.什么情况下会导致服务器端bind绑定的时候失败?

答案:端口被占用或者ip地址错误

4.服务器端listen函数中的第二个参数在Linux系统中指的是已完成三次握手的队列的长度,在Unix系统中指的是未完成三次握手队列和已完成三次握手队列大小之和
在这里插入图片描述
5.服务器端recv的返回值等于0是唯一可以判断客户端关闭了连接的一个依据,不管是客户端close了还是说客户端的进程关闭了,都会返回0值

6.recv和send函数的第四个参数的标志位都是0就可以了

7.什么情况下客户端connect会出错?

答案:服务器关闭,客户端连接的端口和服务器设置的端口不一致,ip输入错误

8.当只./ser运行服务器端时,服务器端阻塞在了accept函数的位置,再运行客户端./cli时,accept成功返回一个连接套接字c = 4,此时服务器端阻塞在recv函数,客户端阻塞在fget这里
在这里插入图片描述9.所以有人会恶意的发很多的SYN,就会导致未完成三次握手的队列被占满,导致正常的SYN无法被响应,这就是SYN洪泛攻击
在这里插入图片描述
10.三次握手的目的是为了建立连接,四次挥手的目的是为了关闭连接

11.客户端close完成2次挥手后,客户端的进程并不会立即结束,而是等待四次挥手结束后,客户端的进程才会结束

12.四次挥手可以是三次吗?

答案:是可以的,第二次和第三次可以合到一起,当服务器收到客户端的FIN时,恰巧服务器也要关闭了,那么就可以把ACK和FIN一起发给客户端,就是三次,但是一般情况下是不会合在一起的,一般情况下都是四次

13.tcp为什么是可靠的?

答案:①应答确认②超时重传③去重④乱序重排⑤滑动窗口来实现流量控制

①应答确认
当a给b发送数据后,b会给a一个回复

②超时重传
如果a给b发送了一个数据,b没有收到,a就会超时重传一次数据,如果b还没有收到,就会继续超时重传,超时重传的代价很高

③去重
也有一种可能是a给b发送了一个数据a后,b给a回复的确认信息丢了,导致a没有收到确认信息,a在等待了一段时间以后,a就会认为b没有收到a发给它的数据,但是实际上b收到了,这个时候a会重新给b发送一个数据a,就会导致b会收到两份甚至更多相同的数据,那么假设b收到一份数据,就会打印一次ok,那么b会打印出两个甚至更多个ok吗?

答案:实际上是不会的,③tcp还有一个功能就是去重,因为每发一个报文它都有一个序号在里面,这个序号可以唯一标识一个报文,tcp发现如果两个报文的序号值是相同的,说明它们是同一个报文,它就会自动帮我们丢弃一个

④乱序重排
a给b不断发送数据,那么第一次a给b发的数据一定就比第二次a给b发的数据先到达b端吗?

答案:不一定
传输层的数据最终要下放到网络层,封装成一个ip报文,ip报文会在数据链路层封装成数据帧,都会通过网络层的ip协议去传送,ip协议不是完全可靠的,它发出去有可能会丢,ip协议并不一定每一次在网络中从a到b传送数据的路径都是一样的,所以对方在收到了数据以后,会根据序号进行重新排序,所以④tcp有一个功能是乱序重排,简单来说就是发送方按照顺序发送数据出去,但是接收方可能接收到的是乱序的,但是tcp会将这些数据依照序号进行重新排序

⑤滑动窗口来实现流量控制
滑动窗口是进行流量控制的,就是一次给对方发送数据的多少

14.tcp的开销很大
客户端给服务器端发送数据a,服务器接受到了数据并向客户端返回了一个ok,我们能看见的只有两次交互,但是实际上交互了四次,翻了一倍,当客户端给服务器端发送数据a后,服务器底层(传输层)会再回复一个tcp报文告诉客户端服务器端收到数据a了,但是这次的交互是tcp在传输层自己完成的,和用户没有关系,用户感知不到这次交互,但是它是存在的,如果我们抓包的话,会发现它在底层确实有这么一次交互,同样,服务器端向客户端回复ok以后,客户端也会向服务器端回复一个确认信息告诉服务器端客户端收到ok了,所以tcp的开销是比较大的,我们能看到的是两次交互,实际上却是四次,翻了一倍,如果我们能看到4次,实际上却是8次

15.滑动窗口

TCP 协议是利用滑动窗口实现流量控制的。一般来说,我们总是希望数据传输得更快一些,不会一次只发一个字节。但是如果发送方把数据发得过快,接受方就可能来不及接收,这就会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快,要让接收方来的及接收

在 TCP 的报头中有一个字段叫做接收通告窗口,这个字段由接收端填充,是接收端告诉发送端自己还有多少缓冲区可以接收数据。于是发送端就可以根据这个接收端的处理能力来发送数据,而不会导致接收端处理不过来。所以发送端就会有一个发送窗口,这个发送窗口的大小是由接收端填充的接收通告窗口的大小决定的,并且窗口的位置会随着发送端数据的发送和接收到接收端对数据的确认而不断的向右滑动,将之称为滑动窗口

只有窗口内的数据才可以发送出去,窗口的大小就是允许一次性发送的最大数据
在这里插入图片描述
16.tcp流式服务
发送端在发送数据的时候,通过send()将数据写入TCP发送缓冲区,在通过若干个TCP报文段(1个2个…几个都有可能)发送给接收端TCP报文段,TCP报文段再把数据传给TCP接收缓冲区,然后接收端再通过recv将数据接收到,这就是流式服务,send和recv并没有一一对应的关系,不是说一个send就必须对应一个recv,可以send三次recv一次,也可以send一次,recv三次,只要发送来的数据都被接收完就行了

注意:helloabcdtest在TCP发送缓冲区中并不能区分hello是一个整体还是helloab是一个整体

粘包:发送端三次发送(第一次hello、第二次abcd、第三次test)的数据helloabcdtest被接收端一次recv就全部接收了,这个就叫做粘包,粘包有时候有影响,有时候没有影响
在这里插入图片描述

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值