深邃 精致 内涵 坚持

主要分析Stable Privacy Address在kernel中的实现codeKernel Version: 4.6无状态地址配置过程一般情况下，在对应的网卡启动的时候，如果支持IPV6，且软件的IPV6功能使能，就会自动配置一个Link local地址，这个link local地址就是以fe80开头，同时有了link local地址之后，系统就会发送一个RS的packet到网络中

参考资料：RFC7217本文主要介绍下Stable Privacy Address，目前在kernel-4.4版本已经引入并且可以使用，默认情况下是关闭的。但是这种类型的地址有一些好处。两种常用地址类型1.全球单播地址Global Unicast Address    这个地址类似IPV4的公网地址，和全球网络上的IPV6服务器进行通信就会使用该类型的地址，全球独一无二。地址格

安全哈希算法（Secure Hash Algorithm）SHA1是一种数据加密的算法，其思想就是将一段明文加密成一个不可逆的密文。 因为是不可逆的，所以是无法通过密文推测出明文的内容，所以这个算法不会被用来进行传输，一般主要是用来进行数据完整性校验。在数字签名之中应用比较广泛， 数字签名的原理是将要传送的明文通过一种函数运算（Hash）转换成报文摘要（不同的明文对应不同的报文摘要），报文摘要加密后与明文一起传送给接受方，接受方将接受的明文产生新的报文摘要与发送方的发来报文摘要解密比较，比较结果一致表

ESP(IPSec Encapsulating Security Payload) ESP相比AH来讲，拥有我们想要的加密功能，协议会通过加密算法将数据和Key将数据进行组合，转换成加密格式，然后送给目的端，先来看下几个比较重要的域。

IPSec核心协议是AH和ESP，本文主要介绍下AH协议的数据封装与传输

目的 1. 实现多个网络接口同时运作，完成多连接的真正并发，多个连接正在的同时访问网络 2. 实现负载均衡，有效扩展带宽增加吞吐量

参考教材：TCP-IP GuideIPSec 介绍IPSec是IP层的一种安全协议，主要作用就是为了解决网络通信中的安全问题。在一般的网络中，暴露这很多的安全问题，比如说数据包被监听窃取，被篡改，以及伪造身份，拒绝服务等。可能在我们使用网络的过程中体会不到网络安全的重要性，可以试想一个场景，你在网络上操作你的网上银行账号，如果你的路由器被窃听，你发送的数据包会被攻击者接收，如果没有

快速重传算法快速重传算法在之前的文章中有介绍，如果收到一个out-of-order的报文段时， TCP需要立刻产生一个ACK，这个ACK不应该被延时，目的在于让对方知道收到一个失序的报文，并告诉对方自己希望收到的报文seq，我们不知道这个重复的ACK的原因，因为还是会等待少量的重复ACK到来，如果连续收到3个或者3个以上的dup ACK，就被判断这个报文被丢失了，于是就需要立即重传丢失的数据段

在网络实际的传输过程中，会出现拥塞的现象，网络上充斥着非常多的数据包，但是却不能按时被传送，形成网络拥塞，其实就是和平时的堵车一个性质了。TCP设计中也考虑到这一点，使用了一些算法来检测网络拥塞现象，如果拥塞产生，变会调整发送策略，减少数据包的发送来缓解网络的压力。

对于segment的重传，重传的时间RTO设定是非常重要的，如果设置太短，可能会导致并没有丢包而重传，如果设置太长了，可能因为等待ACK而浪费掉很多时间，牺牲传输的效率。从思想上来讲，其实我们还是希望重传的时间需要稍稍的大于RTT就可以了。但是这个RTT没有什么可以使用的定值，他是不断变化的。

参考教材：TCP-IP Guide引入理由在文章TCP-IP详解：超时重传机制中，有介绍到快速重传和超时重传都会面临到一个重传什么包的问题，因为发送端也不清楚丢失包后面传送的数据是否有成功的送到。主要原因还是对于TCP的确认系统，不是特别的好处理这种不连续确认的状况了，只有低于ACK number的片段都被收到才有进行ACK，out-of-order的片段只能是等待，同时，这个

超时重传是TCP保证数据传输可靠性的又一大措施

主要介绍再接收端和发送端速率不匹配的状况下，TCP协议栈滑动窗口动态调整机制产生的一种问题 叫糊涂窗口综合症，有关滑动窗口的知识可以参考文章TCP-IP详解：滑动窗口（Sliding Window）

从传输数据来讲，TCP/UDP以及其他协议都可以完成数据的传输，从一端传输到另外一端，TCP比较出众的一点就是提供一个可靠的，流控的数据传输，所以实现起来要比其他协议复杂的多，先来看下这两个修饰词的意义： 1. Reliability ，提供TCP的可靠性，TCP的传输要保证数据能够准确到达目的地，如果不能，需要能检测出来并且重新发送数据。 2. Data Flow Control，提供TCP的流控特性，管理发送数据的速率，不要超过设备的承载能力为了能够实现以上2点，TCP实现了很多细节的功能来保证数

Small Packet Problem 在使用一些协议通讯的时候，比如Telnet，会有一个字节字节的发送的情景，每次发送一个字节的有用数据，就会产生41个字节长的分组，20个字节的IP Header 和 20个字节的TCP Header，这就导致了1个字节的有用信息要浪费掉40个字节的头部信息，这是一笔巨大的字节开销，而且这种Small packet在广域网上会增加拥塞的出现。

先了解一下，TCP传输的数据流的分类：TCP交互数据流：一般情况下数据总是以小于MSS的分组发送，做的是小流量的数据交互，常见的应用比如SSH,Telnet等TCP成块数据流：TCP尽最大能力的运载数据，数据基本都是按照MSS发送，常见的应用有FTP，Iperf等

TCP的头部 TCP属于协议层的第三次，封包被称为segment，现在主要来看下TCP头部的格式，如下图

TCP半打开连接 如果一方已经关闭或者异常终止连接而另外一方却还不知道，这样的连接就称为半打开连接（Half open connection）。处于半打开的连接，如果双方不进行数据通信，是发现不了问题的，只有在通信是才真正的察觉到这个连接已经处于半打开状态，如果双方不传输数据的话，仍处于连接状态的一方就不会检测另外一方已经出现异常

TCP的状态变迁图 一个连接从开始建立到断开，经历了一连串的状态变化，这次主要分析下它的状态变迁图，首先上经典的状态变迁图

参考书籍：TCP-IP详解基本概念：ISN: 初始的序列号，Sequeue Number，TCP 协议栈为每一个封包都会分配一个sequence number，主要用来保证顺序的问题MSS:最大报文长度，发送的报文不要超过这个值，一般情况下MTU-IP Header - TCP HeaderACK:确认序号，表明下一个需要接收的包的Sequeue number，可以通过

新版本中，Android逐渐使用起了socket monitoring的功能，先说应用场景，一般情况下 如果我们使用wifi在看视频的时候，数据包会从server源源不断的输送过来，送到上层的视频APP，但是如果中途我们的wifi断掉的时候，这个connection会怎么样呢？ 其实这时候上层会收到ETIMEOUT的错误，但是这个并不是真正意义上的超时，实际上是Android在kernel做了一种

本文主要分析在发送数据包过程中，设备接口层容易出现的问题及分析思路。从抓包工具中抓出来的网络日志的现象以及其他可疑的点来看可以分为2类：1. 有些数据包被不断的重传（并不是TCP/UDP层的重传），同一个ipid的包不断的被抓到2.数据包被送到netdevice层，但是并没有看到被送到driver

说明：本文主要是分析kernel source code，来贯穿整个network的流程，因为kernel 博大精深，这也仅仅是我的一点愚见，作为一个笔记形式的文章，如有错误，还请指正非常感谢！当上层的APP试图建立一个TCP的链接，或者发送一个封包的时候，在kernel的协议栈部分，在TCP/UDP层会组成一个网络的封包，然后通过IP进行路由选择以及iptables的hokk