关于http:搞定计算机网络的常见面试问题

在浏览器中输出一个 URL 至页面出现，网络上都产生了什么事？

能说说 ISO 七层模型和 TCP/IP 四层模型吗？

TCP/IP 与 HTTP 有什么关系吗？

TCP 协定与 UDP 协定的区别？

请具体介绍一下 TCP 的三次握手机制，为什么要三次握手？挥手却又是四次呢？

具体讲一下 TCP 的滑动窗口？晓得流量管制和拥塞管制吗？

说一下对称加密与非对称加密？

状态码 206 是什么意思？

你们用的 https 是吧，https 工作原理是什么？

…..

通信协议（communications protocol）是指单方实体实现通信或服务所必须遵循的规定和约定。通过通信信道和设施互连起来的多个不同地理位置的数据通信零碎，要使其能协同工作实现信息替换和资源共享，它们之间必须具备独特的语言。交换什么、怎么交换及何时交换，都必须遵循某种相互都能承受的规定。这个规定就是通信协议。

随着技术的倒退，计算机的利用越来越宽泛，计算机之间的通信开始了百花齐放的状态，每个具备独立计算服务体系的信息技术公司都会建设本人的计算机通信规定，而这种状况会导致异构计算机之间无奈通信，极大的妨碍了网络通信的倒退，至此为了解决这个问题，国际标准化组织（ISO）制订了 OSI 模型，该模型定义了不同计算机互联的规范，OSI 模型把网络通信的工作分为 7 层，别离是 物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。

这七层模型是设计层面的概念，每一层都有固定要实现的职责和性能，分层的益处在于清晰和性能独立性，但分层过多会使档次变的更加简单，尽管不须要实现本层的性能，然而也须要结构本层的上下文，空耗系统资源，所以在落地施行网络通信模型的时候将这七层模型简化合并为四层模型别离是 应用层、传输层、网络层、网络接口层（各层之间的模型、协定统称为：TCP/IP 协定簇）。

从上图能够看到，TCP/IP 模型合并了 OSI 模型的应用层、表示层和会话层，将 OSI 模型的数据链路层和物理层合并为网络拜访层。

上图还列出了各层模型对应 TCP/IP 协定栈中的协定以及各层协定之间的关系。比方 DNS 协定是建设在 TCP 和 UDP 协定的根底上，FTP、HTTP、TELNET 协定建设在 TCP 协定的根底上，NTP、TFTP、SNMP 建设在 UDP 协定的根底上，而 TCP、UDP 协定又建设在 IP 协定的根底上，以此类推….

OSI 中的层	性能	TCP/IP 协定族
应用层	文件传输，电子邮件，文件服务，虚构终端	TFTP，HTTP，SNMP，FTP，SMTP，DNS，RIP，Telnet
表示层	数据格式化，代码转换，数据加密	无
会话层	控制应用程序之间会话能力；如不同软件数据分发给不同软件	ASAP、TLS、SSH、ISO 8327 / CCITT X.225、RPC、NetBIOS、ASP、Winsock、BSD sockets
传输层	端到端传输数据的基本功能	TCP、UDP
网络层	定义 IP 编址，定义路由性能；如不同设施的数据转发	IP，ICMP，RIP，OSPF，BGP，IGMP
数据链路层	定义数据的根本格局，如何传输，如何标识	SLIP，CSLIP，PPP，ARP，RARP，MTU
物理层	以二进制数据模式在物理媒体上传输数据	ISO2110，IEEE802

当咱们某一个网站上不去的时候。通常会 ping 一下这个网站

ping 能够说是 ICMP 的最驰名的利用，是 TCP/IP 协定的一部分。利用 ping 命令能够查看网络是否连通，能够很好地帮忙咱们剖析和断定网络故障。

数据在网络中传输最终肯定是通过物理介质传输。物理介质就是把电脑连接起来的物理伎俩，常见的有光纤、双绞线，以及无线电波，它决定了电信号 (0 和 1) 的传输方式，物理介质的不同决定了电信号的传输带宽、速率、传输间隔以及抗干扰性等等。网络数据传输就像快递邮寄，数据就是快件。只有路买通了，你的”快递”能力送到，因而物理介质是网络通信的基石。

寄快递首先得称重、确认体积 (确认数据大小)，贵重物品还得层层包裹填充物确保安全，封装，而后填写发件地址(源主机地址) 和收件地址(指标主机地址)，确认快递形式。对于偏远地区，快递不能中转，还须要中途转发。网络通信也是一样的情理，只不过把这些步骤都规定成了各种协定。

TCP/IP 的模型的每一层都须要下一层所提供的协定来实现本人的目标。咱们来看下数据是怎么通过 TCP/IP 协定模型从一台主机发送到另一台主机的。

当用户通过 HTTP 协定发动一个申请，应用层、传输层、网络互联层和网络拜访层的相干协定顺次对该申请进行包装并携带对应的首部，最终在网络拜访层生成以太网数据包，以太网数据包通过物理介质传输给对方主机，对方接管到数据包当前，而后再一层一层采纳对应的协定进行拆包，最初把应用层数据交给利用程序处理。

TCP/IP（Transmission Control Protocol/Internet Protocol，传输控制协议 / 网际协议）是指可能在多个不同网络间实现信息传输的协定簇。TCP/IP 协定不仅仅指的是 TCP 和 IP 两个协定，而是指一个由 FTP、SMTP、TCP、UDP、IP 等协定形成的协定簇，只是因为在 TCP/IP 协定中 TCP 协定和 IP 协定最具代表性，所以被称为 TCP/IP 协定。

而 HTTP 是应用层协定，次要解决如何包装数据。

“IP”代表网际协议，TCP 和 UDP 应用该协定从一个网络传送数据包到另一个网络。把IP 想像成一种高速公路，它容许其它协定在下面行驶并找到到其它电脑的进口。TCP 和 UDP 是高速公路上的“卡车”，它们携带的货物就是像 HTTP，文件传输协定 FTP 这样的协定等。

都属于传输层协定。

TCP（Transmission Control Protocol，传输控制协议）是面向连贯的协定，也就是说，在收发数据前，必须和对方建设牢靠的连贯。一个 TCP 连贯必须有三次握手、四次挥手。

UDP（User Data Protocol，用户数据报协定）是一个非连贯的协定，传输数据之前源端和终端不建设连贯，当它想传送时就简略地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上

	TCP	UDP
连接性	面向连贯	面向非连贯
传输可靠性	牢靠	不牢靠
报文	面向字节流	面向报文
效率	传输效率低	传输效率高
流量管制	滑动窗口	无
拥塞管制	慢开始、拥塞防止、快重传、快复原	无
传输速度	慢	快
利用场合	对效率要求低，对准确性要求高或要求有连贯的场景	对效率要求高，对准确性要求低

TCP 和 UDP 协定的一些利用

TCP 尽管是面向字节流的，但 TCP 传送的数据单元却是报文段。一个 TCP 报文段分为首部和数据两局部，而 TCP 的全副性能体现在它首部中的各字段的作用。

TCP 报文段首部的前 20 个字节是固定的（下图），前面有 4n 字节是依据须要而减少的选项（n 是整数）。因而 TCP 首部的最小长度是 20 字节。

源端口和目标端口，各占 2 个字节，别离写入源端口和目标端口；
序列号（Sequence number），占 4 字节。序号范畴是【0，2^32 – 1】，共 2^32 个序号。序号减少到 2^32- 1 后，下一个序号就又回到 0。TCP 是面向字节流的。在一个 TCP 连贯中传送的字节流中的每一个字节都按程序编号。整个要传送的字节流的起始序号必须在连贯建设时设置。首部中的序号字段值则是指的是本报文段所发送的数据的第一个字节的序号。例如，一报文段的序号是 301，而接待的数据共有 100 字节。这就表明：本报文段的数据的第一个字节的序号是 301，最初一个字节的序号是 400。显然，下一个报文段（如果还有的话）的数据序号该当从 401 开始，即下一个报文段的序号字段值应为 401。这个字段的序号也叫“报文段序号”;
确认号（Acknowledge number），占 4 个字节，是冀望收到对方下一个报文的第一个数据字节的序号。例如，B 收到了 A 发送过去的报文，其序列号字段是 501，而数据长度是 200 字节，这表明 B 正确的收到了 A 发送的到序号 700 为止的数据。因而，B 冀望收到 A 的下一个数据序号是 701，于是 B 在发送给 A 的确认报文段中把确认号置为 701；
数据偏移，占 4 位，它指出 TCP 报文段的数据起始处间隔 TCP 报文段的起始处有多远。
保留，占 6 位，保留为今后应用，但目前应置为 0；
紧急 URG（URGent），当 URG=1，表明紧急指针字段无效。通知零碎此报文段中有紧急数据；
确认 ACK（ACKnowledgment），仅当 ACK= 1 时，确认号字段才无效。TCP 规定，在连贯建设后所有报文的传输都必须把 ACK 置 1 ；
推送 PSH（PuSH），当两个利用过程进行交互式通信时，有时在一端的利用过程心愿在键入一个命令后立刻就能收到对方的响应，这时候就将 PSH=1；
复位 RST（ReSeT），当 RST=1，表明 TCP 连贯中呈现重大过错，必须开释连贯，而后再从新建设连贯；
同步 SYN（SYNchronization），在连贯建设时用来同步序号。当 SYN=1，ACK=0，表明是连贯申请报文，若批准连贯，则响应报文中应该使 SYN=1，ACK=1；
终止 FIN（FINis），用来开释连贯。当 FIN=1，表明此报文的发送方的数据曾经发送结束，并且要求开释；
- 窗口，占 2 字节，指的是告诉接管方，发送本报文你须要有多大的空间来承受；
测验和，占 2 字节，校验首部和数据这两局部；
紧急指针，占 2 字节，指出本报文段中的紧急数据的字节数；
选项，长度可变，定义一些其余的可选的参数

TCP 是一种面向连贯的单播协定，在发送数据前，通信单方必须在彼此间建设一条连贯。所谓的“连贯”，其实是客户端和服务器的内存里保留的一份对于对方的信息，如 ip 地址、端口号等。

所谓三次握手(Three-way Handshake)，是指建设一个 TCP 连贯时，须要客户端和服务器总共发送 3 个包。

三次握手的目标是连贯服务器指定端口，建设 TCP 连贯，并同步连贯单方的序列号和确认号，替换 TCP 窗口大小信息。

第一次握手(SYN=1, seq=x)
建设连贯。客户端发送连贯申请报文段，这是报文首部中的同步位 SYN=1，同时抉择一个初始序列号 seq=x，此时，客户端过程进入了 SYN-SENT（同步已发送状态）状态。TCP 规定，SYN 报文段（SYN= 1 的报文段）不能携带数据，但须要消耗掉一个序号；
第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1)
服务器收到客户端的 SYN 报文段，如果批准连贯，则收回确认报文。确认报文中应该 ACK=1，SYN=1，确认号 ACKnum=x+1，同时，本人还要发送 SYN 申请信息，SYN=1，为本人初始化一个序列号 seq=y，服务器端将上述所有信息放到一个报文段（即 SYN+ACK 报文段）中，一并发送给客户端，此时，TCP 服务器过程进入了 SYN-RCVD（同步收到）状态。这个报文也不能携带数据，然而同样要耗费一个序号
第三次握手(ACK=1，ACKnum=y+1)
客户端收到服务器的 SYN+ACK 报文段，再次发送确认包(ACK)，SYN 标记位为 0 ，ACK 标记位为 1，确认号 ACKnum = y+1，这个报文段发送结束当前，客户端和服务器端都进入 ESTABLISHED（已建设连贯）状态，实现 TCP 三次握手。

为什么须要三次握手呢？两次不行吗？

为了避免已生效的连贯申请报文段忽然又传送到了服务端，因此产生谬误。

具体例子：“已生效的连贯申请报文段”的产生在这样一种状况下：client 收回的第一个连贯申请报文段并没有失落，而是在某个网络结点长时间的滞留了，以至延误到连贯开释当前的某个工夫才达到 server。原本这是一个早已生效的报文段。但 server 收到此生效的连贯申请报文段后，就误认为是 client 再次收回的一个新的连贯申请。于是就向 client 收回确认报文段，批准建设连贯。假如不采纳“三次握手”，那么只有 server 收回确认，新的连贯就建设了。因为当初 client 并没有收回建设连贯的申请，因而不会理会 server 的确认，也不会向 server 发送数据。但 server 却认为新的运输连贯曾经建设，并始终期待 client 发来数据。这样，server 的很多资源就白白浪费掉了。采纳“三次握手”的方法能够避免上述景象产生。例如方才那种状况，client 不会向 server 的确认收回确认。server 因为收不到确认，就晓得 client 并没有要求建设连贯。”

TCP 的连贯的拆除须要发送四个包，因而称为四次挥手 (Four-way handshake)，也叫做改良的三次握手。 客户端或服务器均可被动发动挥手动作。

第一次挥手(FIN=1，seq=x)
主机 1（能够使客户端，也能够是服务器端），设置 seq=x，向主机 2 发送一个 FIN 报文段；此时，主机 1 进入 FIN_WAIT_1 状态；这示意主机 1 没有数据要发送给主机 2 了；
第二次挥手(ACK=1，ACKnum=x+1)
主机 2 收到了主机 1 发送的 FIN 报文段，向主机 1 回一个 ACK 报文段，Acknnum=x+1，主机 1 进入 FIN_WAIT_2 状态；主机 2 通知主机 1，我“批准”你的敞开申请；
第三次挥手(FIN=1，seq=y)
主机 2 向主机 1 发送 FIN 报文段，申请敞开连贯，同时主机 2 进入LAST_ACK 状态
第四次挥手(ACK=1，ACKnum=y+1)
主机 1 收到主机 2 发送的 FIN 报文段，向主机 2 发送 ACK 报文段，而后主机 1 进入 TIME_WAIT 状态；主机 2 收到主机 1 的 ACK 报文段当前，就敞开连贯；此时，主机 1 期待 2MSL 后仍然没有收到回复，则证实 Server 端已失常敞开，那好，主机 1 也能够敞开连贯了，进入 CLOSED 状态。

主机 1 期待了某个固定工夫（两个最大段生命周期，2MSL，2 Maximum Segment Lifetime）之后，没有收到服务器端的 ACK，认为服务器端曾经失常敞开连贯，于是本人也敞开连贯，进入 CLOSED 状态。

为什么连贯的时候是三次握手，敞开的时候却是四次握手？

因为当 Server 端收到 Client 端的 SYN 连贯申请报文后，能够间接发送 SYN+ACK 报文。其中 ACK 报文是用来应答的，SYN 报文是用来同步的。然而敞开连贯时，当 Server 端收到 FIN 报文时，很可能并不会立刻敞开 SOCKET，所以只能先回复一个 ACK 报文，通知 Client 端，” 你发的 FIN 报文我收到了 ”。只有等到我 Server 端所有的报文都发送完了，我能力发送 FIN 报文，因而不能一起发送。故须要四步握手。

因为 TCP 协定是全双工的，也就是说客户端和服务端都能够发动断开连接。两边各发动一次断开连接的申请，加上各自的两次确认，看起来就像执行了四次挥手。

为什么 TIME_WAIT 状态须要通过 2MSL(最大报文段生存工夫)能力返回到 CLOSE 状态？

尽管按情理，四个报文都发送结束，咱们能够间接进入 CLOSE 状态了，然而咱们必须假象网络是不牢靠的，有能够最初一个 ACK 失落。所以 TIME_WAIT 状态就是用来重发可能失落的 ACK 报文。

还有一个起因，避免相似与“三次握手”中提到了的“曾经生效的连贯申请报文段”呈现在本连贯中。客户端发送完最初一个确认报文后，在这个 2MSL 工夫中，就能够使本连贯继续的工夫内所产生的所有报文段都从网络中隐没。这样新的连贯中不会呈现旧连贯的申请报文。

对于可靠性，TCP 通过以下形式进行保障：

数据包校验：目标是检测数据在传输过程中的任何变动，若校验出包有错，则抛弃报文段并且不给出响应，这时 TCP 发送数据端超时后会重发数据；
对失序数据包重排序：既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的达到可能会失序，因而 TCP 报文段的达到也可能会失序。TCP 将对失序数据进行从新排序，而后才交给应用层；
抛弃反复数据：对于反复数据，可能抛弃反复数据；
应答机制：当 TCP 收到发自 TCP 连贯另一端的数据，它将发送一个确认。这个确认不是立刻发送，通常将推延几分之一秒；
超时重发：当 TCP 收回一个段后，它启动一个定时器，期待目标端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；
流量管制：TCP 连贯的每一方都有固定大小的缓冲空间。TCP 的接收端只容许另一端发送接收端缓冲区所能接收的数据，这能够避免较快主机以致较慢主机的缓冲区溢出，这就是流量管制。TCP 应用的流量控制协议是可变大小的滑动窗口协定。

具体讲一下 TCP 的滑动窗口

如果发送方把数据发送得过快，接管方可能会来不及接管，这就会造成数据的失落。所谓 流量管制 就是让发送方的发送速率不要太快，要让接管方来得及接管。

利用 滑动窗口机制 能够很不便地在 TCP 连贯上实现对发送方的流量管制。

从下面的图能够看到滑动窗口右边的是已发送并且被确认的分组，滑动窗口左边是还没有轮到的分组。滑动窗口外面也分为两块，一块是曾经发送然而未被确认的分组，另一块是窗口内期待发送的分组。随着已发送的分组一直被确认，窗口内期待发送的分组也会一直被发送。整个窗口就会往右挪动，让还没轮到的分组进入窗口内。

能够看到滑动窗口起到了一个限流的作用，也就是说以后滑动窗口的大小决定了以后 TCP 发送包的速率，而滑动窗口的大小取决于拥塞管制窗口和流量管制窗口的两者间的最小值。

TCP 是全双工的，客户端和服务器均可作为发送方或接管方，咱们当初假如一个发送方向接管方发送数据的场景来解说流量管制。首先咱们的接管方有一块接管缓存，当数据来到时会先把数据放到缓存中，下层利用等缓存中有数据时就会到缓存中取数据。如果发送方没有限度地一直地向接管方发送数据，接管方的应用程序又没有及时把接管缓存中的数据读走，就会呈现缓存溢出，数据失落的景象，为了解决这个问题，咱们引入流量管制窗口。

假如应用程序最初读走的数据序号是 lastByteRead，接管缓存中接管到的最初一个数据序号是 lastByteRcv，接管缓存的大小为 RcvSize，那么必须要满足 lastByteRcv – lastByteRead <= RcvSize 能力保障接管缓存不会溢出，所以咱们定义流量窗口为接管缓存残余的空间，也就是 Rcv = RcvSize – (lastByteRcv – lastByteRead)。只有接管方在响应 ACK 的时候把这个窗口的值带给发送方，发送方就能晓得接管方的接管缓存还有多大的空间，进而设置滑动窗口的大小。

拥塞管制是指发送方先设置一个小的窗口值作为发送速率，当胜利发包并接管到 ACK 时，便以指数速率增大发送窗口的大小，直到遇到丢包（超时 / 三个冗余 ACK），才进行并调整窗口的大小。这么做能最大限度地利用带宽，又不至于让网络环境变得太过拥挤。

最终滑动窗口的值将设置为流量管制窗口和拥塞管制窗口中的较小值。

计算机网络中的带宽、替换结点中的缓存及处理机等都是网络的资源。在某段时间，若对网络中某一资源的需要超过了该资源所能提供的可用局部，网络的性能就会变坏，这种状况就叫做拥塞。拥塞管制就是避免过多的数据注入网络中，这样能够使网络中的路由器或链路不致过载。留神，拥塞管制和流量管制不同，前者是一个全局性的过程，而后者指导对点通信量的管制。拥塞管制的办法次要有以下四种：

慢启动：不要一开始就发送大量的数据，先探测一下网络的拥塞水平，也就是说由小到大逐步减少拥塞窗口的大小;
拥塞防止：拥塞防止算法让拥塞窗口迟缓增长，即每通过一个往返工夫 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是加倍，这样拥塞窗口按线性法则迟缓增长。
快重传：快重传要求接管方在收到一个失序的报文段后就立刻收回反复确认（为的是使发送方及早晓得有报文段没有达到对方）而不要等到本人发送数据时捎带确认。快重传算法规定，发送方只有一连收到三个反复确认就该当立刻重传对方尚未收到的报文段，而不用持续期待设置的重传计时器工夫到期。
快复原：快重传配合应用的还有快复原算法，当发送方间断收到三个反复确认时，就执行“乘法减小”算法，把 ssthresh 门限减半，然而接下去并不执行慢开始算法：因为如果网络呈现拥塞的话就不会收到好几个反复的确认，所以发送方当初认为网络可能没有呈现拥塞。所以此时不执行慢开始算法，而是将 cwnd 设置为 ssthresh 的大小，而后执行拥塞防止算法。

大量 CLOSE_WAIT 示意程序呈现了问题，对方的 socket 曾经敞开连贯，而我方忙于读或写没有及时敞开连贯，须要查看代码，特地是开释资源的代码，或者是解决申请的线程配置。

什么 SYN 是洪泛攻打？在 TCP 的三次握手机制的第一步中，客户端会向服务器发送 SYN 报文段。服务器接管到 SYN 报文段后会为该 TCP 调配缓存和变量，如果攻打分子大量地往服务器发送 SYN 报文段，服务器的连贯资源终将被耗尽，导致内存溢出无奈持续服务。

解决策略：当服务器承受到 SYN 报文段时，不间接为该 TCP 分配资源，而只是关上一个半开的套接字。接着会应用 SYN 报文段的源 Id，目标 Id，端口号以及只有服务器本人晓得的一个机密函数生成一个 cookie，并把 cookie 作为序列号响应给客户端。

如果客户端是失常建设连贯，将会返回一个确认字段为 cookie + 1 的报文段。接下来服务器会依据确认报文的源 Id，目标 Id，端口号以及机密函数计算出一个后果，如果后果的值 + 1 等于确认字段的值，则证实是刚刚申请连贯的客户端，这时候才为该 TCP 分配资源

这样一来就不会为歹意攻打的 SYN 报文段分配资源空间，防止了攻打。

HTTP1.0、HTTP1.1、HTTP2.0 的区别

post 和 get 的区别

HTTP 全称是 HyperText Transfer Protocal，即：超文本传输协定。是互联网上利用最为宽泛的一种 网络通信协定，它容许将超文本标记语言（HTML）文档从 Web 服务器传送到客户端的浏览器。目前咱们应用的是HTTP/1.1 版本。所有的 WWW 文件都必须恪守这个规范。设计 HTTP 最后的目标是为了提供一种公布和接管 HTML 页面的办法。1960 年美国人 Ted Nelson 构思了一种通过计算机解决文本信息的办法，并称之为超文本（hypertext），这成为了 HTTP 超文本传输协定规范架构的倒退根基。

每个 Web 服务器资源都有一个名字，这样客户端就能够阐明他们感兴趣的资源是什么了，服务器资源名被称为对立资源标识符（Uniform Resource Identifier,URI）。URI 就像因特网上的邮政地址一样，在世界范畴内惟一标识并定位信息资源。

对立资源定位符（URL）是资源标识符最常见的模式。URL 形容了一台特定服务器上某资源的特定地位。

当初简直所有的 URI 都是 URL。

URI 的第二种模式就是对立资源名（URN）。URN 是作为特定内容的惟一名称应用的，与目前的资源所在地无关。

事务和报文

客户端是怎么通过 HTTP 与 Web 服务器及其资源进行事务处理的呢？一个 HTTP 事务 由一条申请命令（从客户端发往服务器）和一个响应（从服务器发回客户端）后果组成。这种通信是通过名为HTTP 报文（HTTP Message）的格式化数据块进行的。

HTTP 报文是纯文本，不是二进制代码。从 Web 客户端发往 Web 服务器的 HTTP 报文称为申请报文（request message）。从服务器发往客户端的报文称为响应报文。

HTTP 报文包含三局部：

起始行
首部字段
主体

Http 协定定义了很多与服务器交互的办法，最根本的有 4 种，别离是GET,POST,PUT,DELETE. 一个 URL 地址用于形容一个网络上的资源，而 HTTP 中的 GET, POST, PUT, DELETE 就对应着对这个资源的查，改，增，删 4 个操作。咱们最常见的就是 GET 和 POST 了。GET 个别用于获取 / 查问资源信息，而 POST 个别用于更新资源信息。

GET
HEAD
PUT
POST
TRACE
OPTIONS
DELETE

GET 与 POST 是咱们罕用的两种 HTTP Method，二者之间的区别次要包含如下五个方面：

从性能上讲，GET 个别用来从服务器上获取资源，POST 个别用来更新服务器上的资源；
从 REST 服务角度上说，GET 是幂等的，即读取同一个资源，总是失去雷同的数据，而 POST 不是幂等的，因为每次申请对资源的扭转并不是雷同的；进一步地，GET 不会扭转服务器上的资源，而 POST 会对服务器资源进行扭转；
从申请参数模式上看，GET 申请的数据会附在 URL 之后，行将申请数据搁置在 HTTP 报文的申请头中，以? 宰割 URL 和传输数据，参数之间以 & 相连。特地地，如果数据是英文字母 / 数字，原样发送；否则，会将其编码为 application/x-www-form-urlencoded MIME 字符串(如果是空格，转换为 +，如果是中文 / 其余字符，则间接把字符串用 BASE64 加密，得出如：%E4%BD%A0%E5%A5%BD，其中%XX 中的 XX 为该符号以 16 进制示意的 ASCII)；而 POST 申请会把提交的数据则搁置在是 HTTP 申请报文的申请体中。
就安全性而言，POST 的安全性要比 GET 的安全性高，因为 GET 申请提交的数据将明文呈现在 URL 上，而且 POST 申请参数则被包装到申请体中，绝对更平安。
从申请的大小看，GET 申请的长度受限于浏览器或服务器对 URL 长度的限度，容许发送的数据量比拟小，而 POST 申请则是没有大小限度的。

HTTP 申请构造：申请形式 + 申请 URI + 协定及其版本

HTTP 响应构造：状态码 + 起因短语 + 协定及其版本

每条 HTTP 响应报文返回时都会携带一个状态码。状态码是一个三位数字的代码，告知客户端申请是否胜利，或者是都须要采取其余动作。

1xx：表明服务端接管了客户端申请，客户端持续发送申请；
2xx：客户端发送的申请被服务端胜利接管并胜利进行了解决；
3xx：服务端给客户端返回用于重定向的信息；
4xx：客户端的申请有非法内容；
5xx：服务端未能失常解决客户端的申请而出现意外谬误。
200 OK：示意从客户端发送给服务器的申请被失常解决并返回；
204 No Content：示意客户端发送给客户端的申请失去了胜利解决，但在返回的响应报文中不含实体的主体局部（没有资源能够返回）
206 Patial Content：示意客户端进行了范畴申请，并且服务器胜利执行了这部分的 GET 申请，响应报文中蕴含由 Content-Range 指定范畴的实体内容。
301 Moved Permanently：永久性重定向，示意申请的资源被调配了新的 URL，之后应应用更改的 URL；
302 Found：临时性重定向，示意申请的资源被调配了新的 URL，心愿本次拜访应用新的 URL；
303 See Other：示意申请的资源被调配了新的 URL，应应用 GET 办法定向获取申请的资源
304 Not Modified：示意客户端发送附带条件（是指采纳 GET 办法的申请报文中蕴含 if-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since 中任一首部）的申请时，服务器端容许拜访资源，然而申请为满足条件的状况下返回改状态码；
400 Bad Request: 示意申请报文中存在语法错误；
401 Unauthorized：经许可，须要通过 HTTP 认证；
403 Forbidden：服务器回绝该次访问（拜访权限呈现问题）
404 Not Found：示意服务器上无奈找到申请的资源，除此之外，也能够在服务器拒绝请求但不想给回绝起因时应用；
500 Inter Server Error：示意服务器在执行申请时产生了谬误，也有可能是 web 利用存在的 bug 或某些长期的谬误时；
503 Server Unavailable：示意服务器临时处于超负载或正在进行停机保护，无奈解决申请；

HTTP 是个应用层协定。HTTP 无需操心网络通信的具体细节，而是把这些细节都交给了通用牢靠的因特网传输协定 TCP/IP。

在 HTTP 客户端向服务器发送报文之前，须要用网络协议（Internet Protocol，IP）地址和端口号在客户端和服务器之间建设一条 TCP/IP 协定。而 IP 地址就是通过 URL 提供的，像 http://207.200.21.11:80/index.html，还有应用域名服务（Domain Name Services，DNS）的 http://www.lazyegg.net。

HTTP/0.9
HTTP 协定的最后版本，性能简陋，仅反对 GET 办法，并且仅能申请拜访 HTML 格局的资源
HTTP/1.0
- 减少了申请形式 POST 和 HEAD
- 不再局限于 0.9 版本的 HTML 格局，依据 Content-Type 能够反对多种数据格式，即 MIME 多用途互联网邮件扩大，例如 text/html、image/jpeg 等
- 同时也开始反对 cache，就是当客户端在规定工夫内拜访对立网站，间接拜访 cache 即可
- HTTP 申请和回应的格局也变了。除了数据局部，每次通信都必须包含头信息（HTTP header），用来形容一些元数据。其余的新增性能还包含状态码（status code）、多字符集反对、多局部发送（multi-part type）、权限（authorization）、缓存（cache）、内容编码（content encoding）等
- 然而 1.0 版本的工作形式是每次 TCP 连贯只能发送一个申请，当服务器响应后就会敞开这次连贯，下一个申请须要再次建设 TCP 连贯，就是不反对 keepalive
HTTP/1.0+
在 20 世纪 90 年代中叶，为满足飞快倒退的万维网，很多风行的 Web 客户端和服务器飞快的向 HTTP 中增加各种个性，包含长久的 keep-alive 连贯、虚拟主机反对，以及代理连贯反对都被如果到 HTTP 中，并称为非官方的事实标准。这种非正式的 HTTP 扩大版本通常称为 HTTP/1.0+
HTTP/1.1
- http1.1 是目前最为支流的 http 协定版本，从 1997 年公布至今，仍是支流的 http 协定版本。
- 引入了长久连贯，或叫长连贯（persistent connection），即 TCP 连贯默认不敞开，能够被多个申请复用，不必申明 Connection: keep-alive。
- 引入了管道机制（pipelining），即在同一个 TCP 连贯里，客户端能够同时发送多个申请，进一步改良了 HTTP 协定的效率。
- 新增办法：PUT、PATCH、OPTIONS、DELETE。
- http 协定不带有状态，每次申请都必须附上所有信息。申请的很多字段都是反复的，节约带宽，影响速度。
HTTP/2.0（又名 HTTP-NG）
- http/ 2 公布于 2015 年，目前利用还比拟少。
- http/ 2 是一个彻底的二进制协定，头信息和数据体都是二进制，并且统称为 ” 帧 ”（frame）：头信息帧和数据帧。
- 复用 TCP 连贯，在一个连贯里，客户端和浏览器都能够同时发送多个申请或回应，且不必按程序一一对应，防止了队头梗塞的问题, 此双向的实时通信称为多工（Multiplexing）。
- HTTP/2 容许服务器未经请求，被动向客户端发送资源，即服务器推送。
- 引入头信息压缩机制（header compression）, 头信息应用 gzip 或 compress 压缩后再发送。

HTTP 毛病：

通信应用明文不对数据进行加密（内容容易被窃听）
不验证通信方身份（容易假装）
无奈确定报文完整性（内容易被篡改）

因而，HTTP 协定不适宜传输一些敏感信息，比方：信用卡号、明码等领取信息。

为了解决 HTTP 协定的这一缺点，须要应用另一种协定：安全套接字层超文本传输协定 HTTPS，为了数据传输的平安，HTTPS 在 HTTP 的根底上退出了 SSL（安全套接层）协定，SSL 依附证书来验证服务器的身份，并为浏览器和服务器之间的通信加密。

与 SSL（安全套接层）组合应用的 HTTP 就是 HTTPS

img

HTTP 协定传输的数据都是未加密的，也就是明文的，因而应用 HTTP 协定传输隐衷信息十分不平安，为了保障这些隐衷数据能加密传输，于是网景公司设计了 SSL（Secure Sockets Layer）协定用于对 HTTP 协定传输的数据进行加密，从而就诞生了 HTTPS。简略来说，HTTPS 协定是由 SSL+HTTP 协定构建的可进行加密传输、身份认证的网络协议，要比 http 协定平安。

HTTPS 和 HTTP 的区别次要如下：

https 协定须要到 ca 申请证书，个别收费证书较少，因此须要肯定费用。
http 是超文本传输协定，信息是明文传输，https 则是具备安全性的 ssl 加密传输协定。
http 和 https 应用的是齐全不同的连贯形式，用的端口也不一样，前者是 80，后者是 443。
http 的连贯很简略，是无状态的；HTTPS 协定是由 SSL+HTTP 协定构建的可进行加密传输、身份认证的网络协议，比 http 协定平安。

次要的加密办法分为两种：一种是共享密钥加密（对称密钥加密），一种是公开密钥加密（非对称密钥加密）

加密与解密应用同一个密钥，常见的对称加密算法：DES，AES，3DES 等。

img

也就是说在加密的同时，也会把密钥发送给对方。在发送密钥过程中可能会造成密钥被窃取，那么如何解决这一问题呢？

公开密钥应用一对非对称密钥。一把叫公有密钥，另一把叫公开密钥。公有密钥不让任何人晓得，私有密钥随便发送。公钥加密的信息，只有私钥能力解密。常见的非对称加密算法：RSA，ECC 等。

也就是说，发送密文方应用对方的公开密钥进行加密，对方承受到信息后，应用公有密钥进行解密。

对称加密加密与解密应用的是同样的密钥，所以速度快，但因为须要将密钥在网络传输，所以安全性不高。

非对称加密应用了一对密钥，公钥与私钥，所以安全性高，但加密与解密速度慢。

为了解决这一问题，https 采纳对称加密与非对称加密的混合加密形式。

SSL（Secure Sockets Layer），中文叫做“安全套接层”。它是在上世纪 90 年代中期，由网景公司设计的。

SSL 协定就是用来解决 HTTP 传输过程的不平安问题，到了 1999 年，SSL 因为利用宽泛，曾经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化之后的名称改为 TLS（是“Transport Layer Security”的缩写），中文叫做“传输层平安协定”。

很多相干的文章都把这两者并列称说（SSL/TLS），因为这两者能够视作同一个货色的不同阶段。

SSL/TLS 协定的基本思路是采纳公钥加密法，也就是说，客户端先向服务器端索要公钥，而后用公钥加密信息，服务器收到密文后，用本人的私钥解密。

然而，这里有两个问题。

如何保障公钥不被篡改？

解决办法：将公钥放在数字证书中。只有证书是可信的，公钥就是可信的。

公钥加密计算量太大，如何缩小耗用的工夫？
每一次对话（session），客户端和服务器端都生成一个 ” 对话密钥 ”（session key），用它来加密信息。因为 ” 对话密钥 ” 是对称加密，所以运算速度十分快，而服务器公钥只用于加密 ” 对话密钥 ” 自身，这样就缩小了加密运算的耗费工夫。

因而，SSL/TLS 协定的根本过程是这样的：

服务端将非对称加密的公钥发送给客户端；
客户端拿着服务端发来的公钥，对对称加密的 key 做加密并发给服务端；
服务端拿着本人的私钥对发来的密文解密，素来获取到对称加密的 key；
二者利用对称加密的 key 对须要传输的音讯做加解密传输。

HTTPS 相比 HTTP，在申请前多了一个「握手」的环节。

握手过程中确定了数据加密的明码。在握手过程中，网站会向浏览器发送 SSL 证书，SSL 证书和咱们日常用的身份证相似，是一个反对 HTTPS 网站的身份证明，SSL 证书外面蕴含了网站的域名，证书有效期，证书的颁发机构以及用于加密传输明码的公钥等信息，因为公钥加密的明码只能被在申请证书时生成的私钥解密，因而浏览器在生成明码之前须要先核查以后拜访的域名与证书上绑定的域名是否统一，同时还要对证书的颁发机构进行验证，如果验证失败浏览器会给出证书谬误的提醒。

实际上，咱们应用的证书分很多种类型，SSL 证书只是其中的一种。证书的格局是由 X.509 规范定义。SSL 证书负责传输公钥，是一种 PKI（Public Key Infrastructure，公钥根底构造）证书。

咱们常见的证书依据用处不同大抵有以下几种：

SSL 证书，用于加密 HTTP 协定，也就是 HTTPS。
代码签名证书，用于签名二进制文件，比方 Windows 内核驱动，Firefox 插件，Java 代码签名等等。
客户端证书，用于加密邮件。
双因素证书，网银专业版应用的 USB Key 外面用的就是这种类型的证书。

这些证书都是由受认证的证书颁发机构——咱们称之为 CA（Certificate Authority）机构来颁发，针对企业与集体的不同，可申请的证书的类型也不同，价格也不同。CA 机构颁发的证书都是受信赖的证书，对于 SSL 证书来说，如果拜访的网站与证书绑定的网站统一就能够通过浏览器的验证而不会提醒谬误。

为什么服务端要发送证书给客户端

互联网有太多的服务须要应用证书来验证身份，以至于客户端 (操作系统或浏览器等) 无奈内置所有证书，须要通过服务端将证书发送给客户端。

客户端为什么要验证接管到的证书

中间人攻打

客户端 <------------ 攻击者 <------------ 服务端
        伪造证书            拦挡申请

客户端如何验证接管到的证书

为了答复这个问题，须要引入数字签名(Digital Signature)。

+---------------------+
| A digital signature |
|(not to be confused  |
|with a digital       |
|certificate)         |            +---------+              +--------+
| is a mathematical   |---- 哈希 --->| 音讯摘要  |--- 私钥加密 --->| 数字签名 |
|technique used       |            +---------+              +--------+
|to validate the      |
|authenticity and     |
|integrity of a       |
|message, software    |
|or digital document. |
+---------------------+

将一段文本通过哈希（hash）和私钥加密解决后生成数字签名。

假如消息传递在 Bob，Susan 和 Pat 三人之间产生。Susan 将音讯连同数字签名一起发送给 Bob，Bob 接管到音讯后，能够这样验证接管到的音讯就是 Susan 发送的

+---------------------+
| A digital signature |
|(not to be confused  |
|with a digital       |
|certificate)         |            +---------+
| is a mathematical   |---- 哈希 --->|  音讯摘要 |
|technique used       |            +---------+
|to validate the      |                 |
|authenticity and     |                 |
|integrity of a       |                 |
|message, software    |                 对
|or digital document. |                 比
+---------------------+                 |
                                        |
                                        |
          +--------+               +---------+
          | 数字签名 |--- 公钥解密 --->|  音讯摘要 |
          +--------+               +---------+

当然，这个前提是 Bob 晓得 Susan 的公钥。更重要的是，和音讯自身一样，公钥不能在不平安的网络中间接发送给 Bob。此时就引入了证书颁发机构（Certificate Authority，简称 CA），CA 数量并不多，Bob 客户端内置了所有受信赖 CA 的证书。CA 对 Susan 的公钥（和其余信息）数字签名后生成证书。

Susan 将证书发送给 Bob 后，Bob 通过 CA 证书的公钥验证证书签名。

Bob 信赖 CA，CA 信赖 Susan 使得 Bob 信赖 Susan，信赖链（Chain Of Trust）就是这样造成的。

事实上，Bob 客户端内置的是 CA 的根证书(Root Certificate)，HTTPS 协定中服务器会发送证书链（Certificate Chain）给客户端。

Client 应用 https 的 URL 拜访 Server，要求与 Server 建设 SSL 连贯
Server 把当时配置好的公钥证书返回给客户端。
Client 验证公钥证书：比方是否在有效期内，证书的用处是不是匹配 Client 申请的站点，是不是在 CRL 撤消列表外面，它的上一级证书是否无效，这是一个递归的过程，直到验证到根证书（操作系统内置的 Root 证书或者 Client 内置的 Root 证书）。如果验证通过则持续，不通过则显示正告信息。
Client 应用伪随机数生成器生成加密所应用的对称密钥，而后用证书的公钥加密这个对称密钥，发给 Server。
Server 应用本人的私钥（private key）解密这个音讯，失去对称密钥。至此，Client 和 Server 单方都持有了雷同的对称密钥。
Server 应用对称密钥加密“明文内容 A”，发送给 Client。
Client 应用对称密钥解密响应的密文，失去“明文内容 A”。
Client 再次发动 HTTPS 的申请，应用对称密钥加密申请的“明文内容 B”，而后 Server 应用对称密钥解密密文，失去“明文内容 B”。

只管 HTTPS 并非相对平安，把握根证书的机构、把握加密算法的组织同样能够进行中间人模式的攻打，但 HTTPS 仍是现行架构下最平安的解决方案，次要有以下几个益处：

应用 HTTPS 协定可认证用户和服务器，确保数据发送到正确的客户机和服务器；
HTTPS 协定是由 SSL+HTTP 协定构建的可进行加密传输、身份认证的网络协议，要比 http 协定平安，可避免数据在传输过程中不被窃取、扭转，确保数据的完整性。
HTTPS 是现行架构下最平安的解决方案，尽管不是相对平安，但它大幅减少了中间人攻打的老本。
谷歌曾在 2014 年 8 月份调整搜索引擎算法，并称“比起等同 HTTP 网站，采纳 HTTPS 加密的网站在搜寻后果中的排名将会更高”。

尽管说 HTTPS 有很大的劣势，但其相对来说，还是存在不足之处的：

HTTPS 协定握手阶段比拟费时，会使页面的加载工夫缩短近 50%，减少 10% 到 20% 的耗电；
HTTPS 连贯缓存不如 HTTP 高效，会减少数据开销和功耗，甚至已有的安全措施也会因而而受到影响；
SSL 证书须要钱，性能越弱小的证书费用越高，集体网站、小网站没有必要个别不会用。
SSL 证书通常须要绑定 IP，不能在同一 IP 上绑定多个域名，IPv4 资源不可能撑持这个耗费。
HTTPS 协定的加密范畴也比拟无限，在黑客攻击、拒绝服务攻打、服务器劫持等方面简直起不到什么作用。最要害的，SSL 证书的信用链体系并不平安，特地是在某些国家能够管制 CA 根证书的状况下，中间人攻打一样可行。

如果须要将网站从 http 切换到 https 到底该如何实现呢？

这里须要将页面中所有的链接，例如 js，css，图片等等链接都由 http 改为 https。例如：http://www.baidu.com 改为 https://www.baidu.com

BTW，这里尽管将 http 切换为了 https，还是倡议保留 http。所以咱们在切换的时候能够做 http 和 https 的兼容，具体实现形式是，去掉页面链接中的 http 头部，这样能够主动匹配 http 头和 https 头。例如：将 http://www.baidu.com 改为 //www…。而后当用户从 http 的入口进入拜访页面时，页面就是 http，如果用户是从 https 的入口进入拜访页面，页面即便 https 的。

因为 http 协定是无状态协定，如果客户通过浏览器拜访 web 利用时没有一个保留用户拜访状态的机制，那么将不能继续跟踪利用的操作。比方当用户往购物车中增加了商品，web 利用必须在用户浏览别的商品的时候仍保留购物车的状态，以便用户持续往购物车中增加商品。

cookie 是浏览器的一种缓存机制，它可用于维持客户端与服务器端之间的会话。因为上面一题会讲到 session，所以这里要强调 cookie 会将会话保留在客户端（session 则是把会话保留在服务端）

这里以最常见的登陆案例解说 cookie 的应用过程：

首先用户在客户端浏览器向服务器发动登陆申请
登陆胜利后，服务端会把登陆的用户信息设置 cookie 中，返回给客户端浏览器
客户端浏览器接管到 cookie 申请后，会把 cookie 保留到本地（可能是内存，也可能是磁盘，看具体应用状况而定）
当前再次拜访该 web 利用时，客户端浏览器就会把本地的 cookie 带上，这样服务端就能依据 cookie 取得用户信息了

session 是一种维持客户端与服务器端会话的机制。然而与 cookie 把会话信息保留在客户端本地不一样，session 把会话保留在浏览器端。

咱们同样以登陆案例为例子解说 session 的应用过程：

首先用户在客户端浏览器发动登陆申请
登陆胜利后，服务端会把用户信息保留在服务端，并返回一个惟一的 session 标识给客户端浏览器。
客户端浏览器会把这个惟一的 session 标识保留在起来
当前再次拜访 web 利用时，客户端浏览器会把这个惟一的 session 标识带上，这样服务端就能依据这个惟一标识找到用户信息。

看到这里可能会引起疑难：把惟一的 session 标识返回给客户端浏览器，而后保存起来，当前拜访时带上，这难道不是 cookie 吗？

没错，session 只是一种会话机制，在许多 web 利用中，session 机制就是通过 cookie 来实现的。也就是说它只是应用了 cookie 的性能，并不是应用 cookie 实现会话保留。与 cookie 在保留客户端保留会话的机制相同，session 通过 cookie 的性能把会话信息保留到了服务端。

进一步地说，session 是一种维持服务端与客户端之间会话的机制，它能够有不同的实现。以当初比拟风行的小程序为例，论述一个 session 的实现计划：

首先用户登陆后，须要把用户登陆信息保留在服务端，这里咱们能够采纳 redis。比如说给用户生成一个 userToken，而后以 userId 作为键，以 userToken 作为值保留到 redis 中，并在返回时把 userToken 带回给小程序端。
小程序端接管到 userToken 后把它缓存起来，当前每当拜访后端服务时就把 userToken 带上。
在后续的服务中服务端只有拿着小程序端带来的 userToken 和 redis 中的 userToken 进行比对，就能确定用户的登陆状态了。

通过下面两道题的论述，这道题就很清晰了

cookie 是浏览器提供的一种缓存机制，它能够用于维持客户端与服务端之间的会话
session 指的是维持客户端与服务端会话的一种机制，它能够通过 cookie 实现，也能够通过别的伎俩实现。
如果用 cookie 实现会话，那么会话会保留在客户端浏览器中
而 session 机制提供的会话是保留在服务端的。

浏览器查问 DNS，获取域名对应的 IP 地址: 具体过程包含浏览器搜寻本身的 DNS 缓存、搜寻操作系统的 DNS 缓存、读取本地的 Host 文件和向本地 DNS 服务器进行查问等。对于向本地 DNS 服务器进行查问，如果要查问的域名蕴含在本地配置区域资源中，则返回解析后果给客户机，实现域名解析(此解析具备权威性)；如果要查问的域名不禁本地 DNS 服务器区域解析，但该服务器已缓存了此网址映射关系，则调用这个 IP 地址映射，实现域名解析（此解析不具备权威性）。如果本地域名服务器并未缓存该网址映射关系，那么将依据其设置发动递归查问或者迭代查问；
浏览器取得域名对应的 IP 地址当前，浏览器向服务器申请建设链接，发动三次握手；
TCP/IP 链接建设起来后，浏览器向服务器发送 HTTP 申请；
服务器接管到这个申请，并依据门路参数映射到特定的申请处理器进行解决，并将处理结果及相应的视图返回给浏览器；
浏览器解析并渲染视图，若遇到对 js 文件、css 文件及图片等动态资源的援用，则反复上述步骤并向服务器申请这些资源；
浏览器依据其申请到的资源、数据渲染页面，最终向用户出现一个残缺的页面。

XSS 是一种经常出现在 web 利用中的计算机安全漏洞，与 SQL 注入一起成为 web 中最支流的攻击方式。XSS 是指歹意攻击者利用网站没有对用户提交数据进行本义解决或者过滤有余的毛病，进而增加一些脚本代码嵌入到 web 页面中去，使别的用户拜访都会执行相应的嵌入代码，从而盗取用户材料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。

IP 地址是指互联网协议地址，是 IP 协定提供的一种对立的地址格局，它为互联网上的每一个网络和每一台主机调配一个逻辑地址，以此来屏蔽物理地址的差别。IP 地址编址计划将 IP 地址空间划分为 A、B、C、D、E 五类，其中 A、B、C 是根本类，D、E 类作为多播和保留应用，为非凡地址。

每个 IP 地址包含两个标识码（ID），即网络 ID 和主机 ID。同一个物理网络上的所有主机都应用同一个网络 ID，网络上的一个主机（包含网络上工作站，服务器和路由器等）有一个主机 ID 与其对应。A~E 类地址的特点如下：

A 类地址：以 0 结尾，第一个字节范畴：0~127；

B 类地址：以 10 结尾，第一个字节范畴：128~191；

C 类地址：以 110 结尾，第一个字节范畴：192~223；

D 类地址：以 1110 结尾，第一个字节范畴为 224~239；

E 类地址：以 1111 结尾，保留地址

关注公众号：网络技术平台 ，回复“ 材料”获取视频、培训教程、试验手册、电子书。

关于http:搞定计算机网络的常见面试问题

一、计算机网络

通信协议

网络模型

二、TCP/IP

TCP/IP 与 HTTP

TCP 与 UDP

TCP 连贯的建设与终止

TCP 报文首部

TCP 三次握手

TCP 四次挥手

TCP 协定如何来保障传输的可靠性

滑动窗口机制

流量管制

拥塞管制

TCP 的拥塞解决

服务器呈现了大量 CLOSE_WAIT 状态如何解决

讲一讲 SYN 超时，洪泛攻打，以及解决策略

三、HTTP

URI 和 URL

HTTP 音讯的构造

HTTP 事务：

报文：

办法

Get 与 POST 的区别

状态码

协定版本

四、HTTPS

HTTP 和 HTTPS 比照

对称加密与非对称加密

共享密钥加密(对称秘钥加密)

公开密钥（非对称密钥）

SSL/TSL

证书

HTTPS 的工作原理

HTTPS 的长处

HTTPS 的毛病

HTTP 切换到 HTTPS

什么是 Cookie，Cookie 的应用过程是怎么样的？

什么是 session，有哪些实现 session 的机制？

session 和 cookie 有什么区别

Other FAQ

从输出网址到取得页面的过程

XSS 攻打

IP 地址的分类

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）