进阶--网络安全

一.断开连接：四次挥手

标志位是FIN

主动段开方 ->被动断开方 FIN

ps:主动断开方不一定是主动连接方

ACK和FIN可以合并，但不是必须合并

四次挥手的三种可能：

close_wait出现在被动关闭这一方，对方进程要求关闭连接，但我方进程还没要求关闭连接。

time_wait若大量出现，说明我方进程没有关闭连接，可能是服务器忘记写socket.close()了。若只有几个，还是合理的。

time_wait:出现在主动关闭方。

为什么要有这么一个状态，不能直接关闭吗？

1>TCP协议内部怎么区分连接的？通过五元组信息

当一个连接关闭以后，如果之前释放，则五元组信息可能被再次使用。此时，当收到发给这条连接的数据时，不知道数据是给谁的。

2>防止最后一个ACK丢失，对方重新发送

TCP还提供了一种异常关闭的情况。（了解）

收到reste segment之后，TCP直接关闭连接，RST标志位

问题1.直接使用任务管理器关闭一个进程，这个进程持有的这连接会怎么办？

      虽然进程不会执行关闭操作，但是OS会执行四次挥手的正常关闭。

问题2.点击重启，运行着的进程管理的连接会怎么办？

     OS会执行四次挥手的正常关闭。

同理关机也是同样的。

问题3.断电关闭电脑，这个进程持有的这连接会怎么办？

   什么都不会发生：我们这侧的内存中的数据没有了，所以连接从我们这侧，认为已经不存在了。

（没有走任何流程）。

   连接的另一侧，不知道发生了什么。

对方怎么就能知道连接出问题了呢？

    当对方有写操作时，由于多次尝试失败，会发现问题。（但是区分不了对端的问题还是线路的问题），这个感受不是立即的。

当对方只有读操作时，永远发现不了出问题了。

我们进行什么操作，才能必然永远的维护着“死链接”？

1>给 读增加一个超时时间（1天）

2>定期给对方发消息，保平安（heartbeat   心跳包）

二、TCP的流量控制机制--发送量控制

1.为什么减少发送量的控制？ 减少无用功

2.根据对方的接受能力 or线路承载能力   来控制我的发送数据的多少

    狭义流量控制（Flow Control）根据对方的接受能力进行控制

   拥塞控制（Congestion Control）根据网络承载能力进行控制

3.我们怎么知道对方的接受能力？   对方告诉我们的

  对方的接受能力具体是什么？       TCP的接收缓冲区里装的是：对方受到的 && 还没有被应用层                                                           读走。

                                                         TCP的接收缓冲区里还能装多少数据。

对方怎么告诉我们？                 放在TCP首部     

接收能力：接收窗口（receive window）TCP协议每次栈每次发送

我们作为发送方比较实时的知道了对方的接受能力。

我们的发送能力<= 接受窗口！

发送方利用 滑动窗口的机制，进下发送量的控制。

发送缓冲区：应用层写入，将要发送但是还未发送的数据

收到了ACK segment 会携带对方最新的接受能力？

流量控制：

1.接受能力：对方怎么告诉我们的

2.发送如何进下控制：使用滑动窗口机制

拥塞控制：

1.如何得知当前网络的承载能力 ---拥塞窗口

没有一个精确的值，只能采用一些算法来推算出拥塞窗口     

背景：网络质量差，丢包、网络阻塞四非常正常的事情

慢开始+快增长

慢开始：一开始，cwnd很小  cwnd =1

增长阶段：指数阶段 +加法阶段

cwnd = cwnd*2

cwnd = cwnd+2

一旦遇到网络阻塞：单位时间内，重传次数超过一定值

1>.直接把拥塞窗口回到初始值

2>.计算一个新的阈值ssthresh(与之前的网络质量有关）

  ssthresh = cwnd/2

2.发送量（发送窗口） = f(拥塞窗口，接受窗口） 

3.同样按照滑动窗口机制进行控制

标志位：URG +16位紧急指针

标志位：PSH     PSH==0，允许TCP把收到的数据暂存一段时间，集齐一定数量再给应用层

UDP:应用层写成功，数据经过网卡已经到达网络，并没有到达对方

  不可靠    无连接   面向数据报

TCP：应用层写成功，数据存到了发送缓冲区，什么时候发送不知道

    可靠      有链接     面向字节流

---