Please enable JavaScript.

Coggle requires JavaScript to display documents.

TCP (:star:原理 (:three:四次挥手 (:four:第四次挥手 (:one:客户端 (:one:ACK=1, :two…

- - - - :explode:我发给她一个数值,她把数值+1发给我,我只要比较原来的数据+1是不是和她发给我的数值相同就可以了
    - - :one:ACKNOWLEDGEMENT NUMBER:0. SEQUENCE NUMBER:0
        
        :explode:第一次握手的时候,客户端会把SYN标志位置1,并产生序列号X,发送给服务器.
        
        :one:客户端=>
        
        :one:SYN=1
        
        :two:seq=X(随机生成)
      - :two:ACKNOWLEDGEMENT NUMBER:1 SEQUENCE NUMBER:0
        
        :one:服务器=>
        
        :one:ACK=1
        
        :three:SYN=1
        
        :two:ack=X+1
        
        :four:seq=Y
        
        :two:=>客户端
        
        :one:检查
        
        :one:ACK==1
        
        :two:ack==X+1
        
        :two:发送(接第三次握手)
      - :three:客户端在第三次握手的时候,数据包紧接着发出去
        
        :checkered_flag:发数据包是因为客户端已经通过1st和2nd握手知道发出的数据对方能回复,所以直接这里发说数据包
        
        :moneybag:TCP内容
        
        :explode:ACKNOWLEDGEMENT NUMBER:1 SEQUENCE NUMBER:1
        
        :bulb:在HTTP中,当服务器收到3rd握手的消息后,紧接着收到客户端真正的数据包,这个时候服务器(按照老师的视频里的Packet Tracer的话)是要先发送一个ACK(告诉客户端自己收到了客户端真正的数据包),再发送一个请求对应的数据包.
        
        :bulb:不过我这个Packet Tracer里面,服务器收到客户端真正的数据包后,没有回复ACK,而是直接给客户端请求对应的数据包.我不知道是不是Packet Tracer把这两个过程融合在一起了,还是什么原因
        
        :explode:第三次握手的时候,客户端收到后,先检查确认位是否为和ACK
        
        :one:客户端=>
        
        :two:发送
        
        :two:ack=Y+1
        
        :one:ACK=1
        
        :one:检查(接第二次握手)
  - - - :one:客户端
        
        :one:FIN=1
        
        :two:Seq=X
        
        :three:ACK=1
        
        :four:ack=Y
    - - :one:服务端
        
        :two:ack=X+1
        
        :warning:确认包不用回应
        
        :one:ACK=1
        
        :three:Seq=Y
    - - :one:服务端
        
        :one:FIN=1
        
        :two:Seq=Z
        
        :three:ACK=1
        
        :four:ack=X+1
    - - :one:客户端
        
        :one:ACK=1
        
        :two:ack=Y+1
        
        :warning:确认包不用回应
        
        :three:Seq=X+1
      - :link:TIME_WAIT=2MSL
- - - - :bread:1个socket占1个端口.所以总共有6w多个socket,而1秒只能1000多个socket
- - - - PUSH赶快提交
    - - Restart告诉对方必须对方发送FIN
      - 处于礼貌,不自己使用FIN
    - - :icecream:对方传过来的字符太多,我不想接受这么多.如果只是发送普通数据包的话,由于对方流量控制或者什么原因,那么有可能就发送不过去
      - 语法定义为1个字节
      - seq num + urgent pointer为data里的偏移量,指向的字节,那个位置就是紧急数据
        
        允许seq num + urgent pointer跑出data的范围
        
        :arrow_right:目前没有处在urgent,但是通知给接收方说我们可能要处在urgent状态,所以接收方会腾空缓冲区
      - :sweat_drops:drawbacks
        
        :one:seq num+urgent pointer指向的字节的下一个字节才是紧急数据(这是因为第一版本的TCP代码写错了).
        
        :two:实际工作没人使用URG
        
        :snowflake:建立2个TCP连接,一个跑数据,一个跑控制
- - - - :maple_leaf:慢启动
        
        先发一个包,看有没有堵,再发2个包,如果还好,就发4,8个包等,如果不行就使用原来的,不乘2,就+1,到极限后就对折继续加
- - - - :explode:百度流量很高,如果每个人都用长连接的话,会浪费很多资源
- - - - :explode:TCP包内ACK标志置1,ack说明期望接收的数据中第一个字节数据的序号
      - :bread:接收方收到数据后,延迟一会儿再发送数据包=>延迟的时间内有更多数据进来,这样确认包里的ack可以往后移
      - :bulb:TCP都是收到请回复,UDP就不管你收没收到
    - - :explode:发送方在一定时间内没收到确认包,就会重发
      - :bread:TCP发出一个段后会启动一个定时器
- - - - :zap:原因
        
        :two:套接口缓冲区发送和接收都需要一定时间
        
        :tornado:应用程序放到套接口发送缓冲区时部分已经提前发送出去了
        
        :one:数据包分片
        
        :one:IP包的MTU限制
        
        :two:TCP包的MSS限制
        
        :three:发送/接收时都只有一个套接口缓冲区=
        
        :four:TCP的真实数据是字节流
      - :maple_leaf:解决思路
        
        :one:首部指明包大小
        
        :snowflake:发送的时候直接全部发送出去,而接收的时候先接收真实数据的字节长度,然后根据字节长度来接受套接口缓冲区里的数据
        
        :two:结尾用\r\n
        
        :three:定长包
        
        :four:更复杂的应用层协议
      - :explode:由于长连接下发送方连续发送给接收方TCP字节流,接收方不知道套接口缓冲区里取出多少长度的数据,从而导致接收不全/和下一个真实数据接收到一起等错误