契約しているTCP / IP層の構造と機能を持つOSI、
アーキテクチャ5つの協定
私たちは、コンピュータネットワークを研究する場合、一般的に妥協を使用し、それはOSIとTCP / IPの利点である、唯一の5プロトコルアーキテクチャを採用するので、シンプルなコンセプトの両方を明確に説明することができます。
最終的には二つのICMPプロトコルがどの層に属しています
pingコマンドは、ICMPプロトコルの使用です。
ICMPプロトコルIPプロトコル副層である、との間に介在しているIPレイヤ及びTCPレイヤ一般に属すると考え間のプロトコル、IP層プロトコル。
ICMPは、ネットワーク層サプリメントで、メッセージを返すことがあります。ネットワークかどうかを検出するための滑らかな、
Pingコマンドは、ICMP送信されるエコーパケットを、によって返送エコーリレーネットワークテスト。
TCPとUDPの3つの主要な特性と違います
UDPの主な機能
- UDPはコネクションレスです。
- UDPは信頼性の高い配信を保証するものではありませんベストエフォートを使用するため、ホストは、複雑なリンク状態を維持する必要はありません（と多くのパラメータがあります）。
- UDPはのためにあるパケットの。
- UDP ない輻輳制御、ネットワーク輻輳が（のソース・ホストの伝送速度が低下することなく発生し、リアルタイムアプリケーションが有用であるようなIP電話のようなリアルタイムのビデオ会議など）。
- UDPサポート一対一、一対多、多対1と多くの多くのインタラクティブなコミュニケーション。
- UDP ヘッダは、オーバーヘッド、わずか8バイトよりTCPの20バイトのヘッダが短くなっています。
TCPの主な機能
- 指向のTCP コネクションへ。（ただ、電話のように、呼び出しの前にダイヤルアップ接続は、接続の解除をハングアップするために呼び出した後、確立されている必要があるとして）。
- 各TCP接続は、各TCP接続のみ（ポイントを指すことができ、唯一の2つのエンドポイントを有することができ、1対1）。
- TCPは、提供の信頼性の高い配信サービスを。TCPデータ転送、エラーのない介して接続され、失われていない、繰り返し、順番に到着されることはありません。
- TCPは提供し、全二重通信を。両者の間の通信を可能にするTCPアプリケーションプロセスは、いつでもデータを送信することができます。TCP接続の両端が有する送信バッファと受信バッファ通信相手のデータを一時的に記憶するために、
- 指向バイトストリーム。TCP「ストリーム」（ストリーム）内またはプロセスの工程の流出バイトの配列を指します。「指向バイトストリーム」とは：TCPおよびアプリケーションの相互作用があるが、一旦データブロック（サイズ）が、アプリケーションは、専用としてTCPデータをダウン後バイトのストリーム構造化されていないの一連。
TCPとUDPの違い
4は手を振っで四TCP 3ウェイハンドシェイク
なぜSYNを返します
送信者に、受信端を渡し送られたSYNが送信者に伝えることです、私は本当にあなたが送信する信号である情報を受け取りました。
就像钉钉发送完消息，对方显示已读(即已收到)一样，表示已经看过了这条消息。
传了SYN,为啥还要传ACK
双方通信无误必须是两者互相发送信息都无误。传了SYN，证明发送方到接收方的通道没有问题，但是接收方到发送方的通道还需要ACK信号来进行验证。
就像在钉钉上，给别人发消息说你吃饭了没，消息显示已读，但需要对方回复确认信息才知道是否吃饭了。
为什么要四次挥手
任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了TCP连接。
举个例子：A和B打电话，通话即将结束后，A说“我没啥要说的了”，B回答“我知道了”，但是B可能还会有要说的话，A不能要求B跟着自己的节奏结束通话，于是B可能又巴拉巴拉说了一通，最后B说“我说完了”，A回答“知道了”，这样通话才算结束。
五 TCP协议如何保证可靠传输
-
应用数据被分割成TCP认为最适合发送的数据块。
-
超时重传： 当TCP发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。
-
TCP给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
-
校验和： TCP将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP将丢弃这个报文段和不确认收到此报文段。
-
TCP的接收端会丢弃重复的数据。
-
流量控制： TCP连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP使用的流量控制协议是可变大小的滑动窗口协议。 （TCP利用滑动窗口实现流量控制）
-
拥塞控制： 当网络拥塞时，减少数据的发送。
-
停止等待ARQ协议（stop and wait） 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
停止等待协议
-
停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
-
为了提高传输效率，发送方可以不使用低效率的停止等待协议，而是采用流水线传输；流水线传输就是发送方可连续发送多个分组，不必每发完一个分组就停下来等待对方确认。这样可使信道上一直有数据不间断的在传送。这种传输方式可以明显提高信道利用率。
超时重传
停止等待协议中超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。
因此每发送完一个分组需要设置一个超时计时器，其重转时间应比数据在分组传输的平均往返时间更长一些。
这种自动重传方式常称为自动重传请求ARQ；另外在停止等待协议中若收到重复分组，就丢弃该分组，但同时还要发送确认。
连续ARQ协议（流水线传输）可提高信道利用率。发送维持一个发送窗口，凡位于发送窗口内的分组可连续发送出去，而不需要等待对方确认。接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组位置的所有分组都已经正确收到了。
滑动窗口
TCP利用滑动窗口实现流量控制的机制。
发送窗口里面的序号表示允许发送的序号。
发送窗口后沿的后面部分表示已发送且已收到确认，而发送窗口前沿的前面部分表示不允许发送。
发送窗口后沿的变化情况有两种可能，即不动（没有收到新的确认）和前移（收到了新的确认）。
发送窗口的前沿通常是不断向前移动的；一般来说，我们总是希望数据传输更快一些；但如果发送方把数据发送的过快，接收方就可能来不及接收，这就会造成数据的丢失。
所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收的前提让数据传输更快。
流量控制
流量控制是为了控制发送方发送速率，保证接收方来得及接收，让数据传输尽可能的快。
接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。
TCP 滑动窗口协议,窗口过大或过小有什么影响？
滑动窗口的大小对网络性能有很大的影响。
如果滑动窗口过小，极端的情况就是停止等待协议（stop-and-wait），发一个报文，等一个 ACK，会造成通信效率下降。
如果滑动窗口过大，网络容易拥塞，容易造成接收端的缓存不够而溢出，容易产生丢包现象，则需要多次发送重复的数据选择重传协议（selective repeat），耗费了网络带宽。
六 打开一个网页，整个过程会使用哪些协议
图片来源：《图解HTTP》
七 状态码
八 各种协议与HTTP协议之间的关系
图片来源：《图解HTTP》
九 HTTP长连接、短连接
在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样一个Web资源，浏览器就会重新建立一个HTTP会话。
而从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头设置Connection: keep-alive
在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。
HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接
建议
非常推荐大家看一下 《图解HTTP》 这本书，这本书页数不多，但是内容很是充实，不管是用来系统的掌握网络方面的一些知识还是说纯粹为了应付面试都有很大帮助。下面的一些文章只是参考。
来源：