电源完整性要解决的核心问题在于如何保证
PDN（Power Distribution Network，电源分配网络）满足负载芯片对电源的要求。针对PDN典型的设计方法是基于目标阻抗的设计方法：即从IC端看进去的输入阻抗在关注的频率范围内小于目标阻抗，从而使得电源噪声控制在系统的噪声容限范围内。如图2-23所示。
建立连接之后，客户端与服务器端可以互传数据。实际上，在建立连接的过程中，还会确认一些传输参数，例如双方的窗口大小和MSS（Maximum Segment Size，最大报文长度）等。以客户端向服务器端发送数据为例进行说明，并不妨假设客户端窗口为4096字节，MSS为1460字节，服务器端窗口为6144字节，MSS为1024字节。
TCP协议为提高传输效率，支持连续突发传输。且由前面建立连接信息可知，服务器端的窗口为
6144字节，MSS为1024字节。因此，一开始客户端会连续发出6个TCP包，每个包有效数据长度均为
1024字节。随后服务器端发送接收确认信息包，确认号ack为6145，这意味着序号1到6144都已经被正确接收，窗口值win变更为2048；客户端收到服务器端确认包之后，按照确认信息继续发送数据。从序号为6145开始发送，连续发送两个有效数据为1024字节的包。随后服务器端接收数据并更新窗口值。等到服务器发出确认序号为8193，窗口值为6144的确认包，意味着客户端发送过来的8192
字节数据全部正确接收并完成交付，至此双方完成8192字节数据传输。数据传输过程如图2-32所示。
在本设计中，可靠传输机制实现的功能框图如图4-16所示，分为发送部分和接收部分。其中，DDR3
存储模块将在4.2.4中详细说明，硬件配置子模块将在4.2.3中详细说明，组包和解包子模块在上文4.2.2.1节已述，为了方便理解，在本图中从逻辑上将组包解包子模块拆分为组包子模块和解包子模块两个部分，RAM实现对发送和接收的数据包进行缓存，发送状态机SEND_FSM和接收状态机RECV_FSM分别完成发送和接收的控制。图中红色虚线箭头表示两者数据交互并非直接相连，实际上中间需要经过4.2.1节中所述万兆以太网接口模块和万兆光纤。图中紫色虚线箭头指向的紫色虚线方框内分别是RECV_FSM和SEND_FSM两个部分的具体化。
转载：TCP滑动窗口（发送窗口和接受窗口）
TCP窗口机制#
TCP header中有一个Window Size字段，它其实是指接收端的窗口，即接收窗口。用来告知发送端自己所能接收的数据量，从而达到一部分流控的目的。
其实TCP在整个发送过程中，也在度量当前的网络状态，目的是为了维持一个健康稳定的发送过程，比如拥塞控制。因此，数据是在某些机制的控制下进行传输的，就是窗口机制。
窗口缩放因子(Window Scaling)#
以前，window size最大为2的16次方，为65535，随着宽带不断提高，65535字节已经小了，为了突破限制，便有了Window Size Scaling选项，假设window scale为7，也就是要将Window Size的值左移七位，即乘以128。window scale最大为14.
在整个双方的交互过程中，发送方和接收方Window size scaling factor乘积因子必须保持不变，但是发送方的乘积因子和接收方的乘积因子可以不同，由各自决定。
在标志位中有SYN的消息，会在选项中通知接收方，本端具体的放大因子，该消息本身不放大
上图中的放大因子扩大了256倍，8212*256=2102272
发送窗口#
（1）已经发送并且对端确认（Sent/ACKed）---------------发送窗外 缓冲区外
（2）已经发送但未收到确认数据（Sent/UnACKed）----- --发送窗内 缓冲区内
（3）允许发送但尚未防的数据（Unsent/Inside）-----------发送窗内 缓冲区内
（4）未发送暂不允许（Unsent/Outside）-------------------发送窗外 缓冲区内
2，3两部分为发送窗口
接受窗口#
对于TCP的接收方，在某一时刻在它的接收缓存内存在3种。“已接收”，“未接收准备接收”，“未接收并未准备接收”（由于ACK直接由TCP协议栈回复，默认无应用延迟，不存在“已接收未回复ACK”）。其中“未接收准备接收”称之为接收窗口。
发送窗口与接收窗口关系#
TCP是双工的协议，会话的双方都可以同时接收、发送数据。TCP会话的双方都各自维护一个“发送窗口”和一个“接收窗口”。其中各自的“接收窗口”大小取决于应用、系统、硬件的限制（TCP传输速率不能大于应用的数据处理速率）。各自的“发送窗口”则要求取决于对端通告的“接收窗口”，要求相同。
滑动窗口#
TCP并不是每一个报文段都会回复ACK的，可能会对两个报文段发送一个ACK，也可能会对多个报文段发送1个ACK【累计ACK】，比如说发送方有1/2/3 3个报文段，先发送了2,3 两个报文段，但是接收方期望收到1报文段，这个时候2,3报文段就只能放在缓存中等待报文1的空洞被填上，如果报文1，一直不来，报文2/3也将被丢弃，如果报文1来了，那么会发送一个ACK对这3个报文进行一次确认。
滑动窗口实现面向流的可靠性#
最基本的传输可靠性来源于“确认重传”机制。
TCP的滑动窗口的可靠性也是建立在“确认重传”基础上的。
发送窗口只有收到对端对于本段发送窗口内字节的ACK确认，才会移动发送窗口的左边界。
接收窗口只有在前面所有的段都确认的情况下才会移动左边界。当在前面还有字节未接收但收到后面字节的情况下，窗口不会移动，并不对后续字节确认。以此确保对端会对这些数据重传。
滑动窗口的流控特性#
TCP的滑动窗口是动态的，我们可以想象成小学常见的一个数学题，一个水池，体积V，每小时进水量V1，出水量V2。当水池满了就不允许再注入了，如果有个液压系统控制水池大小，那么就可以控制水的注入速率和量。这样的水池就类似TCP的窗口。应用根据自身的处理能力变化，通过本端TCP接收窗口大小控制来对对对端的发送窗口流量限制。
应用程序在需要（如内存不足）时，通过API通知TCP协议栈缩小TCP的接收窗口。然后TCP协议栈在下个段发送时包含新的窗口大小通知给对端，对端按通知的窗口来改变发送窗口，以此达到减缓发送速率的目的。
滑动窗口动态调整#
主要是根据接收端的接收情况，动态去调整Window Size，然后来控制发送端的数据流量
客户端不断快速发送数据，服务器接收相对较慢，看下实验的结果
a. 包175，发送ACK携带WIN = 384，告知客户端，现在只能接收384个字节
b. 包176，客户端果真只发送了384个字节，Wireshark也比较智能，也宣告TCP Window Full
c. 包177，服务器回复一个ACK，并通告窗口为0，说明接收方已经收到所有数据，并保存到缓冲区，但是这个时候应用程序并没有接收这些数据，导致缓冲区没有更多的空间，故通告窗口为0, 这也就是所谓的零窗口，零窗口期间，发送方停止发送数据
d. 客户端察觉到窗口为0，则不再发送数据给接收方
e. 包178，接收方发送一个窗口通告，告知发送方已经有接收数据的能力了，可以发送数据包了
f. 包179，收到窗口通告之后，就发送缓冲区内的数据了.
总结一点，就是接收端可以根据自己的状况通告窗口大小，从而控制发送端的接收，进行流量控制