tracert命令的作用(cmd如何查看NAT转换后的地址)

要查看NAT转换后的地址，可以使用命令行工具cmd。首先使用ipconfig命令获取本地IPv4地址，然后使用tracert命令跟踪到目标主机。

在路由跟踪的过程中，会显示经过的路由器和NAT转换后的地址。通过这些信息可以推断NAT转换后的地址。

另外，也可以使用网络监控工具如Wireshark来捕获网络数据包，从中获取NAT转换后的地址。总之，cmd工具和网络监控工具能够帮助用户查看NAT转换后的地址，提升网络管理和故障排查的效率。

现在黑客太多了，大多数服务器为保证自己地址的安全设置了相关回应机制，比如常用命令：PING，和你的tracert ，设置为当非流量数据传输的时候（比如刚才的测试命令）在数据包发送时不予回应，意思就是你可以连接他的数据和地址。但在用测试命令时它就不对你进行回应。所以就会出现你的这个情况，但实际上他已经对你的数据进行了转发，你的数据传输没有问题，只是你不知道他的地址而已。

另：数据传输不好、运营商安全级别不同也会有上述现象，我就试过在公司tracert 通的网址，换到家里就不通了。

至于你最后连接上了终端并进行了2跳，怀疑是因为数据不稳定系统自动进行了连接重试而已，这个可以在12段看出12段的数据不完全。既然可以到终点就肯定没有环路。 PS:我就是移动公司搞网络维护的，WLAN系统和普通的手机微蜂窝网络根本就是2个系统，没有关联的。WLAN本质上就是一个放大了的无线网络（比普通的家用无线上网覆盖范围要强）因此用在重点的覆盖区域，就如我所说的因为受信号质量影响tracert不通其实是很正常的事情了。

传输层协议延迟时间组成延迟指的就是从发送源到接收源经历的时间带宽指的就是逻辑或物理路径最大的吞吐量

从发送源开始到接收源，中间可能经过很多的基站或者运营商等，那么延迟到底由哪些部分组成呢？从客户端到服务端之间历经的过程会涉及到以下的延迟：

传播延迟：从发送端到接收端的时间，是传播距离与速度的关系传输延迟：传输的信息转移到链路中需要的时间，是消息长度与链路速率的关系处理延迟：处理分组首部、检查位错误以及确定分组目标所需的时间排队延迟：到来的分组排队等待的时间

之前我们介绍过CDN的原理，就是让用户从最近的服务器加载内容，大幅度降低传播分组的时间，在距离与时间的选择当中，我们选择缩短距离的方式来减少加载时间。

其实我们应该明白，造成用户加载时间过慢的原因不是带宽的问题，而是延迟的问题。比如从中国请求美国的网站，中间花的时间不是横跨大洋或者大陆产生的，而是你当前接收的地址（一般是家或者办公室）与最近的服务运营商之间的连接，中间可能会经过多个路由器，路由器进行网络数据的分发，最终才会与运营商连接起来。

在linux平台上可以使用traceroute 命令最终信息的传输过程，计算每一跳所需要的时间，window就通过tracert命令。

高带宽与低延迟

由于人们对视频的需求增长迅速，所以我们提高传输的带宽是非常有必要的，比如部署更多的光纤、拥塞路由之间改善链路、或者使用光纤波分复用（WDN）等技术来让现有的硬件设备传输更多的数据。

WDN:波分复用(WDM)是将两种或多种不同波长的光载波信号(携带各种信息)在发送端经复用器(亦称合波器)汇合在一起，并耦合到光线路的同一根光纤中进行传输的技术；在接收端，经解复用器(亦称分波器或称去复用器)将各种波长的光载波分离，然后由光接收机作进一步处理以恢复原信号。这种在同一根光纤中同时传输两个或众多不同波长光信号的技术,称为波分复用

除了提高带宽，我们也可以利用减少延迟的方式改善，可以让光信号传输的速率更接近光速，如采用折射率更低的材料、速度更快的路由器或者中继器。上面我们就提到过其实信息分组的传输中，延迟是最难以解决的。

TCP的具体构成

「TCP/IP协议」

我们这两种协议并不陌生，IP协议（因特网协议），负责联网主机之间的路由选择与寻址；TCP协议（传输控制协议），负责不可靠的传输信道之上提供可靠的抽象层。对于信息传输的过程中发生的事情，如丢包、拥塞控制等隐藏，所以在优化的时候我们可能会有一些挑战。

「三次握手」

在客户端与服务器进行应用数据交换之前进行操作。

三次握手

在三次握手阶段其实是比较耗费性能的，因此我们想要优化网络也可以从这一方面下手，任何两段数据想要通过TCP传输，那么握手就是必不可少的阶段。谷歌的开发人员研究出一种TCP Fast Open的技术，通过客户端连接时附加一个Cookie（一个TCP选项，此Cookie通常采用一种分组密码，私钥由服务器根据客户端的IP地址保存）来验证是否之前就连接过，如果成功则可以在服务器收到第三个包之前就发送数据。

「拥塞控制及预防」

流量控制

流量控制是一种预防发送端向服务端发送过多数据的一种机制。如果超过了接收端的接收量，可能会造成负载重而处理不过来的情况。每一方都要向对方告知自己的接收窗口，确保能够开辟一个数据缓冲区接收对方的信息。

慢启动

慢启动出现的原因其实就是连接刚建立的双发都不知道网络中可用的带宽是多少，必须要有一个估算的机制，而且这个机制还要随着网络传输的带宽而进行动态变化。我们不可能一上来就完全利用连接的最大带宽，都需要慢慢地传输数据信息以防止网络拥堵。

拥塞预防

当出现丢包的时候，就会认为网络已经出现了拥塞，此时就会采取删包的措施来缓解网络中的某个连接或者路由器的拥塞。然后通过重置拥塞窗口，预防机制按照自己的算法逐步增大窗口，避免丢包。

「队首阻塞」

我们都知道TCP有顺序交付的特点，从一开始的确认应答机制到滑动窗口的机制，前者是只有确认前一个包才可以进行下一个包的发送，后者是允许你发送一定数量的包到接收端，但假如有一个包接收端一直收不到，那就必须停止后面包的发送，重发丢失的包。

所以这里我们就会出现假如一个包要处理很久，那么岂不是后面的都一直等待？这就是队首阻塞问题。

http2中无论在客户端还是在服务器端都不需要排队，在同一个tcp连接上，有多个stream，由各个stream发送和接收http请求，各个steam相互独立，互不阻塞。这就解决了这个问题。

「TCP优化建议」