最近，有位读者问起一个奇怪的事情，他说他想抓一个baidu.com的数据包，体验下看包的乐趣。 但却发现“抓不到”，这就有些奇怪了。 我来还原下他的操作步骤。...在wireshark中搜索baidu的包，发现一无所获 这是为啥？ 到这里，有经验的小伙伴，其实已经知道问题出在哪里了。 为什么没能抓到包 这其实是因为他访问的是HTTPS协议的baidu.com。...而443，则是HTTPS的服务器端口号。 HTTP用的是80端口，如果此时对着80端口抓包，也会抓不到数据。 粗略判断，18号和20号包分别是客户端请求baidu.com的请求包和响应包。...四次握手中，客户端和服务端最后都拥有三个随机数，他们很关键，我特地加粗了表示。 第一次握手，产生的客户端随机数，叫client random。...Client Hello 里的客户端随机数 注意上面的客户端随机数是以 "bff63bbe5"结尾的。 同样，还能在数据报文里拿到server random。
TCP 短连接和长连接的区别 短连接 长连接 TCP粘包、拆包及解决办法 什么是粘包、拆包？ 为什么会发生TCP粘包、拆包？ 粘包、拆包解决办法 为什么常说TCP有粘包和拆包的问题而不说UDP？...从客户端的视角来看，我接到了服务端发送过来的响应数据包，说明服务端接收到了我在第一次握手时发送的网络包，并且成功发送了响应数据包，这就说明，服务端的接收、发送能力正常。...而另一方面，我收到了服务端的响应数据包，说明我第一次发送的网络包成功到达服务端，这样，我自己的发送和接收能力也是正常的。 第三次握手：客户端发包，服务端收到了。...接收端收到了两个数据包，但是这两个数据包要么是不完整的，要么就是多出来一块，这种情况即发生了拆包和粘包。这两种情况如果不加特殊处理，对于接收端同样是不好处理的。 为什么会发生TCP粘包、拆包？...由前两节可知，UDP 是基于报文发送的，UDP首部采用了 16bit 来指示 UDP 数据报文的长度，因此在应用层能很好的将不同的数据报文区分开，从而避免粘包和拆包的问题。
每个主机/路由器都会检查 ARP 请求包中的信息，如果 ARP 请求包中的目标 IP 地址 和自己的相同，就会将自己主机的 MAC 地址写入响应包返回主机 A 由此，可以通过 ARP 从 IP 地址获取...地址进行数据报的发送。...ARP 抓包实战 我们分别演示在 Mac 和 Linux 下的 ARP 报文的截获 在 Mac 环境下，我这边使用的是 WireShark 进行抓包，你可以从官网下载，地址如下 https://www.wireshark.org...使用 tcpdump -i ens33 可以打印出在 ens33 地址下的数据包，下面是我截取的 ARP 数据包。...如果是不完整的映射，那么缓存超时时间为 3 分钟，不完整的映射通常会强制发送一条不存在主机的 ARP 请求。
注意： 接收数据报的主机：可能在一些情况下（广播或者转发），出现目的MAC不是我，我也能收到的情况（后面会提到）。....集线器转发数据报到除主机1的其他所有相连的主机（主机2，主机3） 5.主机2接收：数据报中，目的MAC不是我，丢弃 主机3接收，数据报中，目的MAC是我，接收 目的IP是我，交给对应端口处理，如果不是我...）之后，状态置为closed TCP——>4次挥手中的问题 1.第2步和第3步为什么不能和3次握手流程一样，进行合并 原因：第2步是TCP协议在系统内核中实现时，自动响应的ack 第3步时应用程序手动调用...>为什么要有接收缓冲区和发送缓冲区： 发送端的发送缓冲区：记录已经发送的数据——搜到对应的ACK应答，才可以清理该数据 接收端的接收缓冲区：记录已经接收的数据——如果发送数据报丢包，才知道让对方重发...）之后，状态置为closed TCP——>4次挥手中的问题 1.第2步和第3步为什么不能和3次握手流程一样，进行合并 原因：第2步是TCP协议在系统内核中实现时，自动响应的ack 第3步时应用程序手动调用
Client确认数字证书有效，然后生成呀一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给Server。...四次duplicated ACK更更更可能是丢包造成的，但是这样的响应策略太慢。丢包肯定会造成三次duplicated ACK!综上是选择收到三个重复确认时窗口减半效果最好，这是实践经验。...由于UDP的特性，某一片数据丢失时，接收方便无法重组数据报，导致丢弃整个UDP数据报。 流量控制：当接收方来不及处理发送方的数据，能通过滑动窗口，提示发送方降低发送的速率，防止包丢失。...但是小学生都知道A+B=B+A，假如在传输的过程中有前后两个16比特位的数据前后颠倒了（至于为什么这么巧合？我不知道，也许路由器有bug？也许是宇宙中的高能粒子击中了电缆？...RTT：数据从发送到接收到对方响应之间的时间间隔，即数据报在网络中一个往返用时。大小不稳定。 95、XSS攻击是什么？
作用：在建立连接时由计算机生成的随机数作为其初始值，通过 SYN 包传给接收端主机，每发送一次数据，就「累加」一次该「数据字节数」的大小。用来解决网络包乱序问题。...注意，接收到FIN报文的一方只能回复一个ACK, 它是无法马上返回对方一个FIN报文段的，因为结束数据传输的“指令”是上层应用层给出的，我只是一个“搬运工”，我无法了解“上层的意志”。...然后因为 TCP 延迟确认机制是默认开启的，所以导致我们抓包时，看见三次挥手的次数比四次挥手还多。 2、为什么最后一次挥手，它的 TIME_WAIT 等待的时间是 2MSL？...因为 TCP 报文基于是 IP 协议的，而 IP 头中有一个 TTL 字段，是 IP 数据报可以经过的最大路由数，每经过一个处理他的路由器此值就减 1，当此值为 0 则数据报将被丢弃，同时发送 ICMP...TIME_WAIT 等待 2 倍的 MSL，比较合理的解释是：网络中可能存在来自发送方的数据包，当这些发送方的数据包被接收方处理后又会向对方发送响应，所以一来一回需要等待 2 倍的时间。
ACK都带有对应的确认序列号, 意思是告诉发送者, 我已经收到了哪些数据; 下一次你从哪里开始发 作用： 1.保证安全：保证‘我’发送的消息，对方必须确认并恢复 2.保证多条数据确认信息的安全（告诉发送者...）之后，状态置为closed TCP------>4次挥手中的问题 1.第2步和第3步为什么不能和3次握手流程一样，进行合并 原因：第2步是TCP协议在系统内核中实现时，自动响应的ack 第3步时应用程序手动调用...close来关闭连接的 程序在关闭连接之前，可能需要执行释放资源等前置操作，所以不能合并（TCP协议实现时，没有这样进行设计） 2.第3步中，主机A为什么不能直接设置为closed状态 原因：第4个数据报可能丢包...>为什么要有接收缓冲区和发送缓冲区：发送端的发送缓冲区：记录已经发送的数据——搜到对应的ACK应答，才可以清理该数据 接收端的接收缓冲区：记录已经接收的数据——如果发送数据报丢包，才知道让对方重发 (6...接收端响应的ACK，和主动发送的数据，可以合并返回。
在教师节收到学生提问，刷我B站74小时视频的时候看到我演示了RNA-seq差异分析只用了一行代码就完成了3大R包的全部分析，并且输出了对应的图表结果，觉得很神奇，但是B站视频并没有配套讲义和代码还有测试数据...，为什么这么神奇呢？...下面的图表是如何自动出来的呢？ ? 因为这个 run_DEG_RNAseq 函数的代码非常长，这里我就不贴在公众号了哈，大家可以在我的GitHub的GEO项目找到它！...这个时候是没有标准答案的，因为每个R包都非常热门，引用量都是好几千，你选择哪个都符合市场规律，不过，我这里有一个代码，对3个结果根据阈值筛选交集。...当然是啊，都会写代码了，还有什么是不能为所欲为的呢？ 同样的，代码也是在GitHub，需要你仔细理解，不过我有一个小小的要求，请不要把我的代码雪藏，或者刻意隐瞒。
进入 FIN_WAIT_2 状态；Server 告诉 Client ，我“同意”你的关闭请求； Server 第一次响应后，还可以继续向 Client 发送数据，这里只是告诉 Client ，我收到你发送的关闭请求...第三次挥手 Server 向 Client 发送 FIN 报文段，请求关闭连接，同时 Server 进入 CLOSE_WAIT 状态； 当 Server 的数据响应完成后，再告诉 Client，我这边也可以关闭请求了...生存时间”，这个生存时间是由源主机设置初始值但不是存的具体时间，而是存储了一个ip数据报可以经过的最大路由数，每经过一个处理他的路由器此值就减1，当此值为0则数据报将被丢弃，同时发送ICMP报文通知源主机...TTL与MSL是有关系的但不是简单的相等的关系，MSL要大于等于TTL。 为什么要三次握手？ 为什么要三次握手 TCP 建立连接，其实通过两次握手就可以建立连接了，为什么要三次呢？是不是多此一举呢？...2、网络故障 比如，现在网络出现了故障，只能发请求数据包，而接收不到响应数据包，那么只要发送一次请求，服务器就建立请求，这样肯定也是不对的，网络请求有来有回才能完成通讯。所以三次握手是必不可少的。
下面我来解释一下 TIME_WAIT 状态： MSL(最大分段生存期)指明TCP报文在Internet上最长生存时间，每个具体的TCP实现都必须选择一个确定的MSL值。...但这有两个问题， 第一：我们没有任何机制保证最后的一个ACK能够正常送达 第二：网络上仍然有可能有残余的数据包(wandering duplicates，或老的重复数据包)，我们也必须能够正常处理...这就是为什么socket在关闭后，仍然处于 TIME_WAIT状态，因为他要等待以便重发ACK。...处于TIME_WAIT状态的socket在等待两倍的MSL时间以后（之所以是两倍的MSL，是由于MSL是一个数据报在网络中单向发出到认定丢失的时间，一个数据报有可能在发送图中或是其响应过程中成为残余数据报...，确认一个数据报及其响应的丢弃的需要两倍的MSL），将会转变为CLOSED状态。
而本身，TCP 的三次握手就是为了确保通讯双方能够稳定的建立连接并完成数据报文的请求与响应动作，至于为什么是三次握手而不是四次五次，这是一个哲学问题，这里就不做讨论了。...整体上的意思就是说，「我同意你的连接请求，我的初始序号为 xxx，你的初始序号我收到了，我等着你的下一个分组到来」 第三步： 客户端收到服务端的响应报文，于是分配客户端 TCP 连接所必须的缓存等资源，...第四步： 客户端返回一个 ACK 响应报文，告诉服务端，我收到你刚才发的报文了，我已经确认，你可以关闭连接了。...服务端会紧接着发送它的 FIN 数据报，通知客户端我服务端即将关闭连接，并随即进入 LAST_ACK 状态等待客户端响应报文。...这是为什么客户端等待一个最长报文传输时间的原因。有人可能好奇为什么前面的各次请求都没有做超时等待而只最后一次数据发送做了超时等待？
好吧，图我是直接从百度百科直接粘过来的，因为要我来画，结构也是这样^_^。...3、这个包最终被送到了192.168.220.121的8080端口进行处理，并由下层的Real Server生成了返回的数据报（至于这个Real Server是不是“真正的Real Server”，LVS...使用DR模式时，需要Real Server设置LVS上的VIP为自己的一个回环IP，不然包会被丢弃。这又是为什么呢？很多网贴同样没有回答这个问题，好吧，我们马上回答一下。...那么Real Server节点怎么来判断这个包的正确性呢？...那么Real Server会认为这个包是在本机运行的某一个应用程序通过回环IP发给自己的，所以这个包不能被丢弃，必须处理。 4、被处理后的生成的响应报文，被直接发送给网管。
客户端与服务器之间数据的发送和返回的过程当中需要创建一个叫TCP connection的东西； 由于TCP不存在连接的概念，只存在请求和响应，请求和响应都是数据包，它们之间都是经过由TCP创建的一个从客户端发起...（2）女孩收到男孩的情书后，心花怒放，原来我们是两情相悦呀！于是给男孩写了一封回信：我收到你的情书了，也明白了你的心意，其实，我也喜欢你！我愿意和你交往！...SYN=1，ACK=1表示该报文段为连接同意的应答报文。 seq=y表示服务端作为发送者时，发送字节流的初始序号。 ack=x+1表示服务端希望下一个数据报发送序号从x+1开始的字节。...ACK=1：除TCP连接请求报文段以外，TCP通信过程中所有数据报的ACK都为1，表示应答。 seq=v，v-1是B向A发送的最后一个字节的序号。...为什么要四次挥手 「1」 因为Server端需要将数据给Client端发送完才可以断开连接，假如是三次挥手就可能出现数据还没有发送完就断开了连接，导致数据不完整。
，检查其RARP列表，查找该MAC地址对应的IP地址； （3）如果存在，RARP服务器就给源主机发送一个响应数据包并将此IP地址提供给对方主机使用； （4）如果不存在，RARP服务器对此不做任何的响应...； （5）源主机收到从RARP服务器的响应信息，就利用得到的IP地址进行通讯；如果一直没有收到RARP服务器的响应信息，表示初始化失败。...3.路由选择协议 常见的路由选择协议有：RIP协议、OSRF协议 RIP协议：底层是贝尔曼福特算法，它选择路由的度量标准（metric)是跳数，最大跳数是15跳，如果大于15跳，它就会丢弃数据包。...Client端等待了2MSL后依然没有收到回复，则证明Server端已正常关闭，那好，我Client端也可以关闭连接了。Ok，TCP连接就这样关闭了！ 为什么要三次挥手？ ...为什么要四次挥手？ 试想一下，假如现在你是客户端你想断开跟Server的所有连接该怎么做？第一步，你自己先停止向Server端发送数据，并等待Server的回复。
从客户端的视角来看，我接到了服务端发送过来的响应数据包，说明服务端接收到了我在第一次握手时发送的网络包，并且成功发送了响应数据包，这就说明，服务端的接收、发送能力正常。...而另一方面，我收到了服务端的响应数据包，说明我第一次发送的网络包成功到达服务端，这样，我自己的发送和接收能力也是正常的。 第三次握手：客户端发包，服务端收到了。...而在第三次握手时，服务端收到了客户端对第二次握手作的回应。从服务端的角度，我在第二次握手时的响应数据发送出去了，客户端接收到了。所以，我的发送能力是正常的。而客户端的接收能力也是正常的。...由前两节可知，UDP 是基于报文发送的，UDP首部采用了 16bit 来指示 UDP 数据报文的长度，因此在应用层能很好的将不同的数据报文区分开，从而避免粘包和拆包的问题。...接收端收到了两个数据包，但是这两个数据包要么是不完整的，要么就是多出来一块，这种情况即发生了拆包和粘包。这两种情况如果不加特殊处理，对于接收端同样是不好处理的。 ? ?
大家好，又见面了，我是你们的朋友全栈君。 traceroute原理 traceroute通过ICMP“超时”和“端口不可达”两种消息记录所经过路径的路由。...使用“超时”消息记录经过的路由： traceroute程序发送的数据报首部TTL字段由发送端设置成一个8bit字段。每个处理数据报的路由器都需要把TTL的值减1或减去数据报在路由器中停留的秒数。...由于大多数的路由器转发数据报的时延都小于1秒，因此TTL最终成为一个跳数计数器，每经过一台路由器就将其值减1。 当路由器收到一份IP数据报，如果其TTL字段是0或1，则路由器不转发该数据报。...通常情况下，系统不会接收TTL值为0的数据报。 1 接收到这种数据报的主机是目的主机，直接将其交给应用程序。 2 接收主机不是目的主机，直接将其丢弃，并给发送端发一份ICMP超时消息。...tracert 有一个固定的时间等待响应(ICMP TTL到期消息)。如果这个时间过了，它将打印出一系列的*号表明：在这个路径上，这个设备不能在给定的时间内发出ICMP TTL到期消息的响应。
网络层 『网络层』其实解决的就是一个「转发」的问题，通过传说中的『IP 协议』划分了网络范围，即我没有直接用网线和你连在一起，我也能通过你的 IP 分析出该怎么样找到负责你的网关路由器，并通过你的网关路由给你传输数据报...另外一种呢，就是我们的 DHCP 协议，它允许新加入的主机自动获取一个 IP 地址以及相关的子网掩码和网关地址等。 默认情况下，路由器隔离广播包，不会将收到的广播包从一个子网发送到另一个子网。...这样在链路层广播该数据报的时候，同一子网络下的所有主机都会接受该数据报，但只有 DHCP 服务器会响应这个请求。...而一般情况下服务器会同意并按照你的要求分配出去一块 IP 地址，这也是为什么你每次使用的几乎是同一 IP。...网络层的 IP 数据包会在链路层被封装成『以太网帧』，它的基本结构是这样的： ? 前导码用于同步时钟，按照我的理解就是区分一个一个的帧，源和目的地址指的是『Mac 地址』，也称作物理地址。
网络层 『网络层』其实解决的就是一个「转发」的问题，通过传说中的『IP 协议』划分了网络范围，即我没有直接用网线和你连在一起，我也能通过你的 IP 分析出该怎么样找到负责你的网关路由器，并通过你的网关路由给你传输数据报...另外一种呢，就是我们的 DHCP 协议，它允许新加入的主机自动获取一个 IP 地址以及相关的子网掩码和网关地址等。 默认情况下，路由器隔离广播包，不会将收到的广播包从一个子网发送到另一个子网。...这样在链路层广播该数据报的时候，同一子网络下的所有主机都会接受该数据报，但只有 DHCP 服务器会响应这个请求。...而一般情况下服务器会同意并按照你的要求分配出去一块 IP 地址，这也是为什么你每次使用的几乎是同一 IP。...网络层的 IP 数据包会在链路层被封装成『以太网帧』，它的基本结构是这样的： ?
那为什么就不能直接通过二层的帧在不同网络中进行传输呢？...现在通常认为这个TTL是指数据报允许经过的路由器数，每经过一个路由器，则TTL减1，当TTL值为0时，就丢弃这个数据报。...报文 （1）响应请求 （2）目标不可到达、源抑制和超时报文 （3）时间戳请求 五、路由和路由算法 路由功能其实是一种数据报分组交换路径选择行为，是网络层的一种基本功能。...之所以会出现拥塞现象，就是因为通信子网中所承受的负荷（即通信子网中正在传输的数据包数）超出了网络的吞吐能力（包数/秒）。当通信子网负荷比较小时，网络的吞吐量随网络负荷的增加而线性增加。...❏每个结点配备一个专门的缓冲空间，用以暂存不完整的报文，相当于CPU上配置的多级缓存，但这明显会增加设备的成本。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
腾讯会议
云直播
对象存储
