解决端口使用代理问题

保持前行
查询是否使用了代理:
git config --global http.proxy
取消代理
git config --global --unset http.proxy

帧、数据报、数据包的区别和联系

帧、数据报、数据包的区别和联系
数据链路层之以太网、MAC、MTU详解

一般说来，数据链路层发出的数据包称为frame，地址是链路层的地址，如mac地址；
网络层发出的数据包称为packet，地址是网络层地址，如ip地址；
传输层发出的数据包称为segment/datagram，地址是传输层地址，如TCP的端口号。

比特（Bit）

物理层传输单元。会在帧首部插入8字节：7字节前导同步码（用来迅速实现 MAC帧的比特同步） + 1字节帧开始定界符

数据帧（Frame)

数据链路层的协议数据单元。我们将链路层分组称为帧。
它包括三部分：帧头，数据部分，帧尾。

image.png

IP首部20Byte，UDP首部8Byte，TCP首部20-60Byte

IP报文

五层网络协议

image.png

1、物理层(physical layer)：比特

主要定义物理设备标准，如网线的接口类型、光纤的接口类型、各种传输介质的传输速率等。
它的主要作用是透明地传输比特流。就是由1、0转化为电流强弱来进行传输,到达目的地后在转化为1、0，也就是我们常说的数模转换与模数转换。
　　

2、数据链路层(data link layer)：帧

为网络层提供数据传送服务的，定义了如何让格式化数据以进行传输，以及如何让控制对物理介质的访问。这一层通常还提供错误检测和纠正，以确保数据的可靠传输。

在两个相邻结点之间传送数据时，数据链路层将网络层交下来的IP数据报组装成帧(framing)，在两个相邻结点之间的链路上透明地传送帧中的数据。
每一帧包括数据和必要的控制信息(如同步信息、地址信息、差错控制等)。

注：透明表示，某一个实际存在的事物看起来却好像不存在一样。在数据链路层透明传送数据表示无论什么样的比特组合的数据都能够通过这个数据链路层。
因此，对所传送的数据来说，这些数据就“看不见”数据链路层。或者说，数据链路层对这些数据来说是透明的。

• 在接收数据时，控制信息使接收端能知道一个帧从哪个比特开始和到哪个比特结束。这样，数据链路层在收到一个帧后，就可从中提取出数据部分，上交给网络层。
• 控制信息还使接收端能检测到所收到的帧中有无差错。如发现有差错，数据链路层就简单地丢弃这个出了差错的帧，以免继续传送下去白白浪费网络资源。如需改正错误，就由运输层的TCP协议来完成。

3、网络层(network layer)：数据包

在位于不同地理位置的网络中的两个主机系统之间提供连接和路径选择。
主要包括以下两个任务：

• 负责为分组交换网上的不同主机提供通信服务。在发送数据时，网络层把运输层产生的报文段或用户数据报封装成分组或包进行传送。
• 选中合适的路由，使源主机运输层所传下来的分组，能够通过网络中的路由器找到目的主机。
  协议：IP,ARP,RARP,ICMP,IGMP
  
  
  
  
  
  
  

4、运输层：报文段/用户数据报

负责向两个主机中进程之间的通信提供服务。由于一个主机可同时运行多个进程，因此运输层有复用和分用的功能

复用：就是多个应用层进程可同时使用下面运输层的服务。
分用：就是把收到的信息分别交付给上面应用层中相应的进程。

定义了一些传输数据的协议和端口号（WWW端口80等），主要使用以下两种协议：

• 传输控制协议TCP(transmission control protocol)：面向连接的，传输效率低，用于传输可靠性要求高，数据量大的数据，数据传输的单位是报文段。
  流量控制、序号、确认和定时器、拥塞控制。
• 用户数据报协议UDP(user datagram protocol)：无连接的，用于传输可靠性要求不高，数据量小的数据。不保证提供可靠的交付，只能提供尽最大努力交付数据。传输的单位是用户数据报。
  如QQ聊天数据就是通过这种方式传输的。主要是将从下层接收的数据进行分段和传输，到达目的地址后再进行重组。

TCP首部结构： 博客1(看选项字段)，博客2，TCP首部报文段格式

TCP首部

TCP把连接作为最基本的对象，每一条TCP连接都有两个端点，这种端点我们叫作套接字（socket）。
TCP的数据交互是基于序列号的（控制滑动窗口），发送方通过序列号控制发送数据以及超时重传，接收方通过序列号控制乱序重排。
1.源端口和目的端口，各占2个字节，端口是传输层与应用层的服务接口，传输层的复用和分用功能都要通过端口才能实现。
2.序号，占4个字节，TCP连接中传送的字节流中的每个字节都按顺序编号，这指该报文段所携带数据的第一个字节在整个字节流中的偏移，序列号可以用来解决网络包乱序问题。
3.确认号，占4个字节，用作对另一方发送的tcp报文段的响应。是期望收到对方下一个报文的第一个数据字节的序号。例如，B收到了A发送过来的报文，其序列号字段是501，而数据长度是200字节，这表明B正确的收到了A发送的到序号700为止的数据。因此，B期望收到A的下一个数据序号是701，于是B在发送给A的确认报文段中把确认号置为701。可以用来解决不丢包的问题；
4.数据偏移，占4位，它指出TCP报文的数据距离TCP报文段的起始处有多远，数据偏移最大为4 * 15 = 60，这也是TCP报文段首部的最大长度。

5.保留，占6位，保留今后使用，但目前应都位0；
6.紧急URG，当URG=1，表明紧急指针字段有效。告诉系统此报文段中有紧急数据；
7.确认ACK，仅当ACK=1时，确认号字段才有效。TCP规定，在连接建立后所有报文的传输都必须把ACK置1；
8.推送PSH，当两个应用进程进行交互式通信时，有时在一端的应用进程希望在键入一个命令后立即就能收到对方的响应，这时候就将PSH=1；
9.复位RST，重置连接、复位连接，用来关闭异常的连接;丢弃缓冲区中的包,不必发送ACK包来确认;到不存在的端口的连接请求,异常终止一个连接,检测半打开连接；
10.同步SYN，在连接建立时用来同步序号。当SYN=1，ACK=0，表明是连接请求报文，若同意连接，则响应报文中应该使SYN=1，ACK=1；
11.终止FIN，用来释放连接。当FIN=1，表明此报文的发送方的数据已经发送完毕，并且要求释放链接；
12.窗口，占 2 个字节，窗口值是一个 [0， 216 - 1] 之间的整数。是TCP流量控制的一个手段。窗口指的是发送本报文段的一方的接收窗口（而不是自己的发送窗口）。窗口值用于告诉对方：从本报文段首部中的确认号算起，接受方目前允许对方发送的数据量（以字节为单位）。之所以要有这个限制，是因为接受方的数据空间是有限的；
例如：发送了一个报文段，其确认号是 701，窗口字段值为 1000。这就告诉对方：“从 701 序号开始算起，我（发送此报文段的一方）的接收缓存空间还可以接收 1000 个字节数据，字节序号是 701 - 1700，你在给我发送数据时，必须要考虑到这一点”。窗口字段值明确的指出了现在允许对方发送的数据量，窗口值通常是在不断的动态变化着。
13.检验和，占2字节，由发送端填充，接收端对tcp报文段执行CRC算法以检验TCP报文段在传输过程中是否损坏。校验首部和数据这两部分；
14.紧急指针，占2字节，指出本报文段中的紧急数据的字节数；
15.选项，长度可变，定义一些其他的可选的参数；
16.填充，为了使整个首部长度是 4 字节的整数倍。

5、应用层(application layer)：报文

直接为用户的应用进程（例如电子邮件、文件传输和终端仿真）提供服务。
在因特网中的应用层协议很多：如支持万维网应用的HTTP(S)协议，支持电子邮件的SMTP协议，支持文件传送的FTP协议，DNS，POP3，SNMP，Telnet等等。
注：
FTP基于TCP协议
应用层中的会话层：
通过运输层（端口号：传输端口与接收端口）建立数据传输的通路。主要在你的系统之间发起会话或者接受会话请求（设备之间需要互相认识可以是IP也可以是MAC或者是主机名） 　　
应用层中的表示层：
可确保一个系统的应用层所发送的信息可以被另一个系统的应用层读取。例如，PC程序与另一台计算机进行通信，其中一台计算机使用扩展二一十进制交换码（EBCDIC），而另一台则使用美国信息交换标准码（ASCII）来表示相同的字符。如有必要，表示层会通过使用一种通格式来实现多种数据格式之间的转换。

DNS协议

主要使用UDP协议，也会使用TCP协议。
参考：博客
对于绝大多数的 DNS 查询来说都会使用 UDP 数据报进行传输，TCP 协议只会在区域传输的场景中使用，其中 UDP 数据包只会传输最大 512 字节的数据，多余的会被截断；发现 UDP 包被截断时应该通过 TCP 协议重试。



DNS递归和迭代过程详解



递归查询
在该模式下DNS 服务器接收到客户机请求，必须使用一个准确的查询结果回复客户机。如果DNS 服务器本地没有存储查询DNS 信息，那么该服务器会询问其他服务器，并将返回的查询结果提交给客户机。

迭代查询
DNS 服务器会向客户机提供其他能够解析查询请求的DNS 服务器地址，当客户机发送查询请求时，DNS 服务器并不直接回复查询结果，而是告诉客户机另一台DNS 服务器地址，客户机再向这台DNS 服务器提交请求，依次循环直到返回查询的结果为止。
递归查询和迭代查询
递归的含义就是DNS服务器作为DNS客户端向其他DNS服务器查询此解析请求，直到获得解析结果，在此过程中，原DNS客户端则等待DNS服务器的回复。
递归和迭代的不同之处就是当DNS服务器没有在本地完成客户端的请求解析时，由谁扮演DNS客户端的角色向其他DNS服务器发起解析请求。

Socket

socket编程
scp file user@192.168..:/home
套接字：它的定义为端口号拼接到IP地址即构成了套接字，例如，若IP地址为192.3.4.16 而端口号为80，那么得到的套接字为192.3.4.16:80。
Archlinux开启ssh服务命令：
systemctl enable sshd.service 开机启动
systemctl start sshd.service 立即启动
systemctl restart sshd.service 立即重启

常用的熟知端口号

三次握手，四次挥手

博客1：seq和ack号的正确理解
博客2：各个状态名称与含义
博客3：详解+动图
博客4：知乎

TCP首部

ACK：用于对收到的数据进行确认，所确认的数据由确认序列号表示。
SYN：用作建立连接时的同步信号。
FIN：表示后面没有数据需要发送，通常意昧着所建立的连接需要关闭了。

TCP连接建立

QQ截图20200225222728.png

image.png

第一步：A 机器向 B机器发出一个数据包并将 SYN 设置为 1 ，表示希望建立连接。这个包中的ACK位为0，序列号seq假设是 X。此时A状态为SYN_SENT； TCP规定，SYN报文段（SYN=1的报文段）不能携带数据，但需要消耗掉一个序号。

第二步：B机器收到A机器发过来的数据包后，通过 SYN，ACK 得知这是一个建立连接的请求，于是发送一个响应包并将 SYN 、ACK 标记都置为 1。假设序列号seq=y ，而确认序列号ack必须是 x+1，表示收到了发过来的 SYN。此时状态由LISTEN变为SYN_RECV。这个报文也不能携带数据，但是同样要消耗一个序号。

第三步：A 收到响应包后需进行确认ack是否正确以及位码ACK是否为1。若正确，A会再发送ACK位号=1，确认序列号ack=y+1，seq=x+1(我这方的数据流就从这个数开始)的包。主机B收到后确认seq值与ack=1，则连接建立成功，双方状态ESTABLISHED。TCP规定，ACK报文段可以携带数据，但是如果不携带数据则不消耗序号。

为什么要三次握手呢？

主要是为了信息对等和防止出现请求超时导致脏连接。
第一是为了保证两台机器信息对等，确保两台机器都没有什么问题。只有三次握手之后才能够保证两台服务器都完全没有问题，各自具备发报和收报能力。

image.png

第二是防止出现请求超时导致脏连接，看下面这张图：

image.png

为什么会出现脏连接？因为TTL 网络报文的生存时间往往都会超 TCP 请求超时时间，如果两次握手就可以创建连接 ，传输数据并释放连接后，第一个超时的连接请求才到达 B 机器的话，B 机器会以为是 A 创建新连接的请求，然后确认同意创建连接。因为 A 机器的状态不是 SYl_SENT ，所以直接丢弃了 B 的确认数据 ，以致最后只是 B 机器单方面创建连接完毕。
三次握手就可以解决这个问题，因为需要 A 服务器确认了才真正的建立了连接。

为什么TCP客户端最后还要发送一次确认呢？

一句话，主要防止已经失效的连接请求报文突然又传送到了服务器，从而产生错误。
如果使用的是两次握手建立连接，假设有这样一种场景，客户端发送了第一个请求连接并且没有丢失，只是因为在网络结点中滞留的时间太长了，由于TCP的客户端迟迟没有收到确认报文，以为服务器没有收到，此时重新向服务器发送这条报文，此后客户端和服务器经过两次握手完成连接，传输数据，然后关闭连接。此时此前滞留的那一次请求连接，网络通畅了到达了服务器，这个报文本该是失效的，但是，两次握手的机制将会让客户端和服务器再次建立连接，这将导致不必要的错误和资源的浪费。
如果采用的是三次握手，就算是那一次失效的报文传送过来了，服务端接受到了那条失效报文并且回复了确认报文，但是客户端不会再次发出确认。由于服务器收不到确认，就知道客户端并没有请求连接。

为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？

这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一 个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文 和FIN报文多数情况下都是分开发送的。

建立连接的时候， 服务器在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。
而关闭连接时，服务器收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，而自己也未必全部数据都发送给对方了，所以己方可以立即关闭，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送，从而导致多了一次。

如果已经建立了连接，但是客户端突然出现故障了怎么办？

TCP还设有一个保活计时器，显然，客户端如果出现故障，服务器不能一直等下去，白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器，时间通常是设置为2小时，若两小时还没有收到客户端的任何数据，服务器就会发送一个探测报文段，以后每隔75秒发送一次。若一连发送10个探测报文仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

TCP连接的释放 四次挥手

A：B 啊，我不想玩了。
B：哦，你不想玩了啊，我知道了。
这个时候，还只是 A 不想玩了，也即 A 不会再发送数据，但是 B 能不能在 ACK 的时候，直接关闭呢？当然不可以了，很有可能 A 是发完了最后的数据就准备不玩了，但是 B 还没做完自己的事情，还是可以发送数据的，所以称为半关闭的状态。
这个时候 A 可以选择不再接收数据了，也可以选择最后再接收一段数据，等待 B 也主动关闭。
B：A 啊，好吧，我也不玩了，拜拜。
A：好的，拜拜。

4次挥手.png

1.客户端进程发出连接释放报文，并且停止发送数据。释放数据报文首部，FIN=1，其序列号为seq=u（等于前面已经传送过来的数据的最后一个字节的序号加1），此时，客户端进入FIN-WAIT-1（终止等待1）状态。 TCP规定，FIN报文段即使不携带数据，也要消耗一个序号。
2.服务器收到连接释放报文，发出确认报文，ACK=1，ack=u+1，并且带上自己的序列号seq=v，此时，服务端就进入了CLOSE-WAIT（关闭等待）状态。TCP服务器通知高层的应用进程，客户端向服务器的方向就释放了，这时候处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若发送数据，客户端依然要接受。这个状态还要持续一段时间，也就是整个CLOSE-WAIT状态持续的时间。
3.客户端收到服务器的确认请求后，此时，客户端就进入FIN-WAIT-2（终止等待2）状态，等待服务器发送连接释放报文（在这之前还需要接受服务器发送的最后的数据）。
4.服务器将最后的数据发送完毕后，就向客户端发送连接释放报文，FIN=1，ack=u+1，由于在半关闭状态，服务器很可能又发送了一些数据，假定此时的序列号为seq=w，此时，服务器就进入了LAST-ACK（最后确认）状态，等待客户端的确认。
5.客户端收到服务器的连接释放报文后，必须发出确认，ACK=1，ack=w+1，而自己的序列号是seq=u+1，此时，客户端就进入了TIME-WAIT（时间等待）状态。注意此时TCP连接还没有释放，必须经过（最长报文段寿命）的时间后，当客户端撤销相应的TCB后，才进入CLOSED状态。
6.服务器只要收到了客户端发出的确认，立即进入CLOSED状态。同样，撤销TCB后，就结束了这次的TCP连接。可以看到，服务器结束TCP连接的时间要比客户端早一些。

关闭TCP连接一定需要4次挥手吗?

不一定，4次挥手关闭TCP连接是最安全的做法。但在有些时候，我们不喜欢TIME_WAIT 状态(如当MSL数值设置过大导致服务器端有太多TIME_WAIT状态的TCP连接，减少这些条目数可以更快地关闭连接，为新连接释放更多资源)，这时我们可以通过设置SOCKET变量的SO_LINGER标志来避免SOCKET在close()之后进入TIME_WAIT状态，这时将通过发送RST强制终止TCP连接(取代正常的TCP四次握手的终止方式)。但这并不是一个很好的主意，TIME_WAIT 对于我们来说往往是有利的。

为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？

因为虽然双方都同意关闭连接了，而且握手的4个报文也都发送完毕，按理可以直接回到CLOSED 状态(就好比从SYN_SENT 状态到ESTABLISH 状态那样)，但是我们必须假想网络是不可靠的，你无法保证你(客户端)最后发送的ACK报文一定会被对方收到，就是说对方处于LAST_ACK 状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT 状态的作用就是用来重发可能丢失的ACK报文。

MSL（Maximum Segment Lifetime），TCP允许不同的实现可以设置不同的MSL值。
第一，保证客户端发送的最后一个ACK报文能够到达服务器，因为这个ACK报文可能丢失，站在服务器的角度看来，我已经发送了FIN+ACK报文请求断开了，客户端还没有给我回应，应该是我发送的请求断开报文它没有收到，于是服务器又会重新发送一次，而客户端就能在这个2MSL时间段内收到这个重传的报文，接着给出回应报文，并且会重启2MSL计时器。
第二，防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后，在这个2MSL时间中，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。

要求 A 等待 TIME_WAIT还有一个原因就是防止产生混乱，A 直接关闭了，但是这个时候 B是不知道的，可能在 A 关闭之前 B还发送了很多数据包，如果这时候 A 的端口被一个新的应用占用了的话，那么新的应用就会接收到上个连接中 B发送过来的数据包，这样就混乱了，虽然这个数据包是无效的，但是等待 TIME_WAIT 可以是一个双保险，因而也需要等足够长的时间，等到原来 B 发送的所有的包都死翘翘，再空出端口来。

昂贵的资源

上面分析可知，三次握手和四次挥手无疑会造成巨大的网络资源和CPU资源的消耗（如果连接没有被复用，这就是一种浪费），另外，客户端和服务端分别要维护各自的发送和接收缓存，各自在操作系统里面的变量（比如文件描述符，操作系统维护的一套数据结构），在阻塞式的网络模型中，服务端还要开启线程来处理这条连接。所以说TCP连接是比较昂贵的资源，需要连接池这种技术来提高它的复用性。

TCP连接
TCP超时,重传机制,拥塞避免,计时器

TCP中的RST标志(Reset)详解
TCP协议RST：RST介绍、什么时候发送RST包
什么是滑动窗口和拥塞窗口
TCP的滑动窗口与拥塞窗口
发送窗口的值 取 接收窗口和拥塞窗口中的最小值。

TCP/IP： 超时，重传，控流，拥塞处理
TCP的超时重传之深入了解RTT与RTO
TCP/IP详解 卷1 第二十一章 TCP的超时与重传
TCP-超时与重传
TCP超时重传、滑动窗口、拥塞控制、快重传和快恢复

udp和tcp的区别

udp和tcp的区别，tcp的流量控制，拥塞控制，tcp怎样保证可靠传输

输入网址到网页显示的过程是什么？

输入网址到网页显示的过程是什么？

1. 在客户端浏览器中输入网址URL。
2. 发送到DNS(域名服务器)获得域名对应的WEB服务器的IP地址。
3. 客户端浏览器与WEB服务器建立TCP(传输控制协议)连接。
4. 客户端浏览器向对应IP地址的WEB服务器发送相应的HTTP或HTTPS请求。
5. WEB服务器响应请求，返回指定的URL数据或错误信息；如果设定重定向，则重定向到新的URL地址。
6. 客户端浏览器下载数据，解析HTML源文件，解析的过程中实现对页面的排版，解析完成后，在浏览器中显示基础的页面。
7. 分析页面中的超链接，显示在当前页面，重复以上过程直至没有超链接需要发送，完成页面的全部显示。

数字证书

百度百科：数字证书
数字证书

HTTPS

http和https的区别，https是如何加密的，它的加密方式是怎样
https://www.jianshu.com/p/14cd2c9d2cd2
https://blog.csdn.net/xiaoming100001/article/details/81109617
https://baike.baidu.com/item/https/285356?fr=aladdin