修改

maxlzc · Aug 4, 2018 · 7dd9405 · 7dd9405
1 parent 95950ac
commit 7dd9405
Show file tree

Hide file tree

Showing 4 changed files with 18 additions and 6 deletions.
diff --git a/interview/网络.md b/interview/网络.md
@@ -17,7 +17,7 @@
         * 15）http[请求](https://github.com/arkingc/note/blob/master/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C.md#1http%E6%8A%A5%E6%96%87%E6%A0%BC%E5%BC%8F%E8%AF%B7%E6%B1%82%E6%8A%A5%E6%96%87)/[响应报文](https://github.com/arkingc/note/blob/master/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C.md#2http%E6%8A%A5%E6%96%87%E6%A0%BC%E5%BC%8F%E5%93%8D%E5%BA%94%E6%8A%A5%E6%96%87)构成
         * 16）[DNS？](https://github.com/arkingc/note/blob/master/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C.md#34-dns%E5%9F%9F%E5%90%8D%E7%B3%BB%E7%BB%9F)（[查询过程？](https://github.com/arkingc/note/blob/master/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C.md#2dns%E6%9F%A5%E8%AF%A2%E6%AD%A5%E9%AA%A4)[DNS记录？](https://github.com/arkingc/note/blob/master/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C.md#3dns%E8%AE%B0%E5%BD%95%E5%92%8C%E6%8A%A5%E6%96%87)）
     * **2.运输层**
-        * 1）[一个机器能够使用的端口号上限是多少，为什么？可以改变吗？那如果想要用的端口超过这个限制怎么办？](https://www.cnblogs.com/solohac/p/4154180.html) 
+        * 1）一个机器能够使用的端口号上限是多少，为什么？可以改变吗？那如果想要用的端口超过这个限制怎么办？
         * 2）[TCP](https://github.com/arkingc/note/blob/master/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C.md#5tcp)和[UDP](https://github.com/arkingc/note/blob/master/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C.md#3udp)的区别（什么时候用TCP，什么时候用UDP、首部？）
         * 3）[TCP和UDP相关的协议与端口号](https://github.com/arkingc/note/blob/master/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C.md#11-%E7%AB%AF%E5%8F%A3%E5%8F%B7)
         * 4）[TCP为什么需要三次握手和四次挥手？](https://github.com/arkingc/note/blob/master/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C/%E8%AE%A1%E7%AE%97%E6%9C%BA%E7%BD%91%E7%BB%9C.md#53-%E8%BF%9E%E6%8E%A5%E7%AE%A1%E7%90%86)

diff --git a/数据结构与算法/算法题总结.md b/数据结构与算法/算法题总结.md
@@ -16285,7 +16285,7 @@ private:
 
 ### 解答
 
-假设`state[i][j]`表示单词`word1.substr(0,i + 1)`转换成单词`word2.substr(0,j + 1)`的最少：
+假设`state[i][j]`表示单词`word1.substr(0,i + 1)`转换成单词`word2.substr(0,j + 1)`的最少操作数：
 
 * 当`word1[i] == word2[j]`时，`state[i][j] = state[i - 1][j - 1]`
 * 否则，可以进行三种操作：

diff --git a/计算机网络/UNIX网络编程卷1.md b/计算机网络/UNIX网络编程卷1.md
@@ -1071,7 +1071,7 @@ struct linger{
 
 SO_REUSEPORT的问题在于并非所有系统都支持。在那些不支持该选项但是支持多播的系统上，改用SO_REUSEADDR以允许合理的完全重复的捆绑
 
-> SO_REUSEADDR有一个潜在的安全问题。举例来说，假设存在一个绑定了通配地址和端口5555的套接字，如果指定SO_REUSEADDR，我们就可以把相同的端口捆绑到不同的IP地址上，譬如说就是所在主机的主IP地址。此后目的地端口为5555及新绑定IP地址的数据报将被递送到新的套接字，而不是递送到绑定了通配地址的已有套接字。这些数据报可以是TCP的SYN分节、STP的INIT块或UDP数据报。对于大多数众所周知的服务如HTTP、FTP和Telnet来说，这不成问题，因为这些服务器绑定的是保留端口。这种情况下，后来的试图捆绑这些端口更为明确的实例（也就是盗用这些端口）的任何进程都需要超级用户特权。然后NFS可能是一个问题，因为它的通常端口2049并不是保留端口
+> SO_REUSEADDR有一个潜在的安全问题。举例来说，假设存在一个绑定了通配地址和端口5555的套接字，如果指定SO_REUSEADDR，我们就可以把相同的端口捆绑到不同的IP地址上，譬如说就是所在主机的主IP地址。此后目的地端口为5555及新绑定IP地址的数据报将被递送到新的套接字，而不是递送到绑定了通配地址的已有套接字。这些数据报可以是TCP的SYN分节、STP的INIT块或UDP数据报。对于大多数众所周知的服务如HTTP、FTP和Telnet来说，这不成问题，因为这些服务器绑定的是保留端口。这种情况下，后来的试图捆绑这些端口更为明确的实例（也就是盗用这些端口）的任何进程都需要超级用户特权。然而NFS可能是一个问题，因为它的通常端口2049并不是保留端口
 
 ### 2.2 TCP套接字选项
 

diff --git a/计算机网络/计算机网络.md b/计算机网络/计算机网络.md
@@ -457,10 +457,12 @@ UDP能提供运输层最低限度的两个服务：**差错检测、数据交付
 
 UDP首部只有4个字段，每个字段2个字节，一共8个字节大小的首部
 
-**校验和**：对报文段中的所有16比特字（不包括校验和本身）的和相加（如有溢出会卷回）的结果取反就是校验和。在接收方，会将所有16比特字的和相加，如果分组无差错，这个和会是“1111-1111-1111-1111”（为了方便阅读，使用'-'分隔）
+**校验和**：对报文段中的所有16比特字（包括数据部分，不包括校验和本身）的和相加（如有溢出会卷回）的结果取反就是校验和。在接收方，会将所有16比特字的和相加，如果分组无差错，这个和会是“1111-1111-1111-1111”（为了方便阅读，使用'-'分隔）
 
 许多链路层协议提供了差错检测，UDP还需提供校验和的原因在于，不能确保所有链路都提供了差错检测。此外，即使报文段经链路正确地传输，当其存储在某台路由器的内存中时，也可能引入比特差错。既未确保逐段链路的可靠性，也未确保内存中的差错检测，因此UDP必须在端到端基础上在运输层提供差错检测
 
+> **校验和**方法需要相对小的分组开销。例如，TCP和UDP中的校验和只用了16比特。然而与常用于链路层的CRC(循环冗余检测)相比，他们提供相对弱的差错保护。**运输层使用校验和而链路层使用CRC的原因是：**运输层通常在主机中作为用户操作系统的一部分并用软件实现，因此采用简单而快速（如校验和）的差错检测方案是重要的。另一方面，链路层的差错检测在适配器中用专业硬件实现，它能快速地执行更复杂的CRC操作
+
 ## 4 可靠数据传输原理
 
 * **rdt**：可靠数据传输
@@ -605,10 +607,20 @@ LastByteSent - LastByteAcked <= RcvWindow
 
 **如果客户端不发送ACK来完成第三次握手，最终(通常是一分钟后)服务器将终止该半开连接并回收已分配的资源（在第三次握手前分配缓存和变量，可能会受到SYN洪泛攻击）**
 
+**如果第二次握手丢包怎么办？第三次呢？**[——知乎车小胖的回答](https://www.zhihu.com/question/24853633)
+
+* **第二个包，即B发给A的SYN +ACK 中途被丢，没有到达A**
+    - B会周期性超时重传，直到收到A的确认
+* **第三个包，即A发给B的ACK 中途被丢，没有到达B**
+    A发完ACK，单方面认为TCP为 Established状态，而B显然认为TCP为Active状态
+    - **假定此时双方都没有数据发送**：B会周期性超时重传，直到收到A的确认，收到之后B的TCP 连接也为Established状态，双向可以发包
+    - **假定此时A有数据发送**：B收到A的 Data + ACK，自然会切换为established 状态，并接受A的Data
+    - **假定B有数据发送**：数据发送不了，会一直周期性超时重传SYN + ACK，直到收到A的确认才可以发送数据
+
 **SYN cookies预防SYN洪泛攻击**：
 
-* 当服务器接收到一个SYN报文段时，它并不知道该报文段是来自一个合法的用户，还是一个SYN洪泛攻击的一部分。因此服务器不会为该报文段生成一个半开TCP连接。相反，服务器生成一个初始TCP序列号，该序列号是SYN报文段的源和目的IP地址、端口号以及仅被该服务器所知的秘密数的一个散列函数，称作“cookie”。服务器发送具有这种特殊序列号的SYNACK分组，服务器并不记忆该cookie或任何对应于SYN的其他状态信息
-* 如果客户机是合法的，它将返回一个ACK报文段。服务器一旦收到该ACK，需要验证与前面发送的某些SYN对应的ACK。对于一个合法的ACK，确认字段中的值等于SYNACK字段中的值加1。服务器将使用在ACK报文段中的相同字段和秘秘数运行相同的函数。如果该函数的结果加1与确认号相同，服务器就认为该ACK对应于前面发送的SYN报文段，生成一个具有套接字的全开的连接
+* 当服务器接收到一个SYN报文段时，它并不知道该报文段是来自一个合法的用户，还是一个SYN洪泛攻击的一部分。因此服务器不会为该报文段生成一个半开TCP连接。相反，服务器生成一个**初始TCP序列号y**，该序列号是SYN报文段的**源和目的IP地址、端口号**以及仅被该服务器所知的**秘密数**的一个散列函数，这种精心制作的初始序列号被称作“cookie”。服务器发送具有这种特殊序列号的SYNACK分组，服务器并不记忆该cookie或任何对应于SYN的其他状态信息
+* 如果客户机是合法的，它将返回一个ACK报文段。服务器一旦收到该ACK，需要验证与前面发送的某些SYN对应的ACK。对于一个合法的ACK，确认字段中的值等于SYNACK序号字段y的值加1。服务器将使用在ACK报文段中的相同字段和秘密数运行相同的函数。如果该函数的结果加1与确认号相同，服务器就认为该ACK对应于前面发送的SYN报文段，生成一个具有套接字的全开的连接
 * 如果客户机没有返回一个ACK报文段，则初始化的SYN也没有对该服务器产生危害，因为服务器没有为它分配任何资源
 
 **前两次“握手”不包含有效载荷，第三次“握手”可以承载有效载荷**