三次握手

学习总结 Sniffer（嗅探器） 嗅探器是一种常用的收集有用数据方法，这些数据可以是用户的帐号和密码，可以是一些商用机密数据等等。Snifffer可以作为能够捕获网络报文的设备,ISS为Sniffer这样定义：Sniffer是利用计算机的网络接口截获目的地为其他计算机的数据报文的一种工具。 SNIFFER要捕获的东西必须是要物理信号能收到的报文信息。显然只要通知网卡接收其收到的所有包（一般叫做杂收promiscuous模式：指网络上的所有设备都对总线上传送的数据进行侦听，并不仅仅是它们自己的数据。），在HUB下就能接收到这个网段的所有包，但是交换机下就只能是自己的包加上广播包。 要想在交换机下接收别人的包，那就要让其发往你的机器所在口。交换机记住一个口的MAC是通过接收来自这个口的数据后并记住其源MAC，就像一个机器的IP与MAC对应的ARP列表，交换机维护一个物理口与MAC的表，所以可以欺骗交换机的。可以发一个包设置源MAC是你想接收的机器的MAC，那么交换机就把你机器的网线插的物理口与那个MAC对应起来了，以后发给那个MAC的包就发往你的网线插口了，也就是你的网卡可以Sniffer到了。注意这物理口与MAC的表与机器的ARP表一样是动态刷新的，那机器发包后交换HUB就又记住他的口了，所以实际上是两个在争，这只能应用在只要收听少量包就可以的场合。

1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接 2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付 3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的 UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等） 4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信 5、TCP首部开销20字节;UDP的首部开销小，只有8个字节 6、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道 三次握手与四次挥手 三次握手通俗版： 第一次握手：客户端要和服务端进行通信，首先要告知服务端一声，遂发出一个SYN=1的连接请求信号,”服务端哥哥，我想给你说说话”。 第二次握手：当服务端接收到客户端的连接请求，此时要给客户端一个确认信息，”我知道了（ACK）,我这边已经准备好了，你现在能连吗（SYN）”。 第三次握手：当客户端收到了服务端的确认连接信息后，要礼貌的告知一下服务端，“好的，咱们开始联通吧（ACK）”。 到此整个建立连接的过程已经结束，接下来就是双方你一句我一句甚至同时交流传递信息的过程了。 四次挥手断开连接通俗版： 第一次挥手

3 月，跳不动了？>>> 缓存的分类有很多种，CDN缓存、数据库缓存、代理服务器缓存和浏览器缓存。造成强制缓存的字段有两个Expires和Cache-Control。 Expires Expires: Thu, 10 Nov 2017 08:45:11 GMT 是一个绝对时间，在响应消息头中，设置这个字段之后，就可以告诉浏览器，在未过期之前不需要再次请求。 Cache-Control 该字段表示资源缓存的最大有效时间，在该时间内，客户端不需要向服务器发送请求，相对时间， max-age：即最大有效时间，在上面的例子中我们可以看到 no-cache：表示没有缓存，即告诉浏览器该资源并没有设置缓存 s-maxage：同max-age，但是仅用于共享缓存，如CDN缓存 public：多用户共享缓存，默认设置 private：不能够多用户共享，HTTP认证之后，字段会自动转换成private。 ` Cache-Control: max-age=2592000` 对比缓存 先从缓存中获取对应的数据标识，然后向服务器发送请求，确认数据是否更新，如果更新，则返回新数据和新缓存；反之，则返回304状态码，告知客户端缓存未更新，可继续使用。 缺点： 1. 如果资源更新的速度是秒以下单位，那么该缓存是不能被使用的，因为它的时间单位最低是秒。 2.如果文件是通过服务器动态生成的

TCP是因特网中的传输层协议，使用三次握手协议建立连接，下面是TCP建立连接的全过程。 上图画出了TCP建立连接的过程。假定主机A是TCP客户端，B是服务端。最初两端的TCP进程都处于CLOSED状态。图中在主机下面的是TCP进程所处的状态。A是主动打开连接，B是被动打开连接。 首先A向B发出连接请求报文段，这时首部中的同步位SYN=1，同时选择一个初始序号seq=x。TCP规定，SYN报文段不能携带数据，但要消耗掉一个序号。这时，A进入SYN-SENT状态。 B收到请求后，向A发送确认。在确认报文段中把SYN和ACK位都置为1，确认号是ack=x+1,同时也为自己选择一个初始序号seq=y。请注意，这个报文段也不能携带数据，但同样要消耗掉一个序号。这时B进入SYN-RCVD状态。 A收到B的确认后，还要向B给出确认。确认报文段的ACK置为1，确认号ack=y+1，而自己的序号seq=x+1。这时，TCP连接已经建立，A进入ESTABLISHED状态，当B收到A的确认后，也会进入ESTABLISHED状态。 以上给出的连接建立过程就是常说的TCP三次握手。 为什么A还要发送一次确认呢?这主要是为了防止已失效的连接请求报文段突然又传送到了B，因而产生错误。 所谓已失效的连接请求报文段是这样产生的。A发送连接请求，但因连接请求报文丢失而未收到确认，于是A重发一次连接请求

在移动APP开发中。网络通信数据传输是必定存在的。移动APP离开了网络通信数据传输的功能方式，就好比一潭死水，永远都 是原来的样子。 提到网络通信传输数据。首先出如今程序猿脑海中的是HTTP协议传输，然而要深沉次的挖掘HTTP协议的传输原理， 那么久会有一个Socket的长连接数据传输的方式。HTTP协议数据传输，分为Get、POST两种请求方式，而Socket长连接也有两种方 式，一种是TCP协议的传输方式，还有一种是UDP协议的传输方式。在此。我觉得Socket的理解例如以下： 一、 Socket定义： Socket 是应用层与 TCP/IP 协议族通信的中间软件抽象层。它是一组接口。在设计模式中， Socket 事实上就是一个门面模式， 它把复杂的 TCP/IP 协议族隐藏在 Socket 接口后面。对用户来说，一组简单的接口就是所有，让 Socket 去组织数据，以符合指定 的协议。 二、基于TCP/IP协议的Socekt 1、 使用 Socket 实现client的步骤； 1 、通过 IP 地址和port实例化 Socket, 请求连接server 2 、获取 Socket 上的流以进行读写 3 、把流包装进 BufferReader/PrintWriter 的实例 4 、对 Socket 进行读写 5 、关闭打开的流 创建server的步骤： 1

为什么要三次握手: ① 防止失效的链接到达服务器服务器打开错误链接。 ② 客户端如果长时间等待,会有一个超时重传,但是之前那个被耽误的请求还是会回到服务器,服务器会打开两个连接。 ③ 有三次握手后客户端会忽视滞留请求。 为什么要四次挥手。 ① 当客户端发送连接释放报名后,服务器端数据可能还没有 传输完。 为什么客户端接收了FIN报文还要等2msl,而非直接 closed? ① 确保最后一个确认能到达服务器, ② 让本次连接持续时间内产生的所有报文都在网络上消失，不影响下一次连接。 （我的字为什么这么丑，一定是ipad的锅） 来源： https://www.cnblogs.com/crushxz/p/12539996.html

背景 和女朋友异地恋一年多，为了保持感情我提议每天晚上视频聊天一次。 从好上开始，到现在，一年多也算坚持下来了。 问题 有时候聊天的过程中，我的网络或者她的网络可能会不好，视频就会卡住，听不到对方的声音，过一会儿之后才会恢复。 中间双方可能就要不断的确认网络是否恢复，但是有时候会： 她：“你可以听到了吗？” 我：“可以了，你呢？”、 她：“喂喂，你可以听到了吗？” 我：“可以了，我可以听到了，你呢？” 她：“你可以听到了吗？” ..... 这种情况很蛋疼，那么怎样才能找一个简单的办法，让两个人都确认自己可以听到对方的声音，对方也可以听到自己的声音呢？ 注：以下情节纯属虚构 方案 TCP建立连接为什么是三次握手，而不是两次或四次？ TCP，名为传输控制协议，是一种可靠的传输层协议，IP协议号为6。 顺便说一句，原则上任何数据传输都无法确保绝对可靠，三次握手只是确保可靠的基本需要。 举个日常例子，打电话时我们对话如下： 对应为客户端与服务器之间的通信： 于是有了如下对话： 我：1+1等于几？ 她：2,2+2等于几？ 我：4 首先两个人约定协议 1.感觉网络情况不对的时候，任何一方都可以发起询问 2.任何情况下，若发起询问后5秒还没收到回复，则认为网络不通 3.网络不通的情况下等1min路由器之后再发起询问 对于我而言，发起 “1+1等于几”的询问后 1. 若5s内没有收到回复

3 月，跳不动了？>>> 首先来看看OSI的七层模型： 我们需要知道TCP工作在网络OSI的七层模型中的第四层——Transport层，IP在第三层——Network层，ARP( 是根据 IP地址 获取 物理地址 的一个 TCP/IP协议 )在第二层——Data Link层；在第二层上的数据，我们把它叫Frame，在第三层上的数据叫Packet，第四层的数据叫Segment。 同时，我们需要简单的知道，数据从应用层发下来，会在每一层都会加上头部信息，进行封装，然后再发送到数据接收端。这个基本的流程你需要知道，就是每个数据都会经过数据的封装和解封装的过程。 在OSI七层模型中，每一层的作用和对应的协议如下： TCP连接的建立（三次握手） 客户端发送（主动）一个SYN给服务端（相当于告诉服务端，我要打开连接了，你注意一下）。客户端的状态变化：CLOSED–> SYN_SENT，服务端状态变化：CLOSED–>LISTEN; 服务端收到SYN报文，发送SYN+ACK两个报文给客户端，其中ACK报文是对客户端发来的SYN报文的确认（相当于告诉客户端，我收到你的连接请求了）。而这里的SYN报文则是服务端主动给客户端发送的请求连接报文（相当于告诉客户端，我要和你建立连接了，你注意一下）。服务端的状态变化：LISTEN–>SYN RECEIVED，客户端的状态无变化 客户端收到服务端的SYN

3 月，跳不动了？>>> 先上一段大学书本内容： 这幅图大家应该并不陌生吧，引用下结论 为了实现可靠数据传输， TCP 协议的通信双方， 都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的。 三次握手的过程即是通信双方相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤 结论应该还算可以简单理解吧，没理解也没关系，其实3次握手我们可以理解为是确定双方接收发送能力的过程，也就是说作为看客户端你需要知道你自己的接收发送能力没问题，也需要知道服务端的接收发送能力没问题，反之亦然，也就是对应每方都需要知道四种状态，三次握手的过程就总共要确认这8种状态，具体过程是：第一次客户端发送命令给服务端，服务端收到，这一过程服务端确认了客户端的发送能力和自己的接收能力；第二次服务端发送命令回客户端，这一过程客户端确认了自己的发送能力和接收能力以及服务端的发送能力和接收能力没问题都没问题；至此，我们只剩下服务端方面确认客户端的接收能力和它自己的发送能力了，所以第三次握手的作用就体现在此了。当然这个过程是用什么来确认的，那就是上面提到的序列号啦。会不会有点绕，其实按着这个流程画一下图应该就能理解了，2的立方不就等于8嘛。 来源： oschina 链接： https://my.oschina.net/u/4247262/blog/3207314

3 月，跳不动了？>>> QUIC ，即 快速UDP网络连接 ( Quick UDP Internet Connections )， 是由 Google 提出的实验性网络传输协议 ，位于 OSI 模型传输层。 QUIC 旨在解决 TCP 协议的缺陷，并最终替代 TCP 协议， 以减少数据传输，降低连接建立延迟时间，加快网页传输速度。 QUIC 主要特点有： 多流设计； 低等待延迟； 加密性能更优； 前向纠错； 应用程序实现； 连接保持； 多流设计 采用 多路复用 思想，一个连接可以同时承载多个 流 ( stream )，同时发起多个请求。 请求间完全 独立 ，某个请求阻塞甚至报文出错均不影响其他请求。 对比 HTTP 长连接，由于 TCP 是只实现一个字节流，如果请求阻塞，新请求无法发起。 低等待延迟 先考察典型的 TLS 连接建立过程： 首先，执行三次握手，建立 TCP 连接(蓝色部分)； 然后，执行 TLS 握手，建立 TLS 连接(黄色部分)； 此后开始传输业务数据； 客户端和服务器之间要进行好几轮协议交互，才能建立 TLS 连接，延迟相当严重。 平时访问 https 网站明显比 http 网站慢，三次握手和 TLS 握手难辞其咎。 > 注解: > > 注意到，三次握手中的 ACK 包与 ClientHello 合并在一起发送。 这是 TCP 实现中使用的 延迟确认 技术