文章标题网络协议计算机网络体系结构OSI层模型TCP/IP模型TCP/IP协议族TCP和UDP地址及端口号确定端口号和协议TCP/IPTCP握手TCP三握手协议
网络协议计算机网络体系结构OSI层模型
开放系统互联参考模型(Open System Interconnect简称OSI )是国际标准化
由组织(ISO )和国际电报电话咨询委员会(CCITT )共同制定的开放系统互联参考模型，
为开放的互联信息系统提供功能结构框架。 其目的是异构计算机的互联
提供共同的基础和标准框架，为维护相关标准的一致性和兼容性提供共同的参考。 这里所说开放系统，实质上是指遵从OSI
通过参照模型和相关协议，可以实现可互联的具有各种APP应用目的的计算机系统。
OSI采用分层结构化技术，共分为七层：物理层、数据链路层、网络层、传输层、传输层、呈现层、APP应用层。
由于TCP/IP模型OSI模型既复杂又学术，我们实际使用的TCP/IP模型共4层，如图所示，为链路层、网络层、传输层、应用层2个模型之间的对应关系
在任何模式下，每个抽象层都建立在低层提供的服务之上，并为高层提供服务。
TCP/IP协议家族传输控制协议/互联网协议的简称。 中国名称是传输控制协议/互联网互联协议，是互联网最基本的协议、互联网国际互联网络的基础，由网络层的IP协议和传输层的TCP协议组成。 协议采用四层分层结构。 但是，在很多情况下，是利用IP进行通信时所需的协议群的总称。 也就是说，它其实是一个协议家族，由很多协议组成，在不同的层，是互联网的基础设施。
在TCP和UDP上表中，互联网协议IP是TCP/IP中非常重要的协议。 将IP地址(发送它的主机的地址(源地址)和接收的主机的地址(目标地址) ) )和其他数据添加到数据中以确定传输目的地。
TCP和UDP是传输层协议，传输层主要为两台主机上的APP应用程序提供端到端通信。
但是，TCP和UDP最不同的地方是TCP提供面向连接的可靠的数据传输服务。 这意味着，使用TCP通信的两台主机将首先经历建立连接的过程，直到建立连接，才开始传输数据。 另外，在传输中采用“重发肯定应答”技术实现传输的可靠性。 TCP还以一种称为“滑动窗口”的方式进行流量控制，发送完成后关闭连接。 所以TCP比UDP可靠得多。
用户数据报协议(UDP ) (userdatagramprotocol的简称，中国名称是用户数据报协议)直接发送数据，对方是否接收到、是否接收到，也不需要接收方的确认，是不可靠的传输，存在丢包现象
注意：我们的一些常见网络APP应用程序基本上基于TCP和UDP。 这些协议使用网络层的IP协议。 但是，您也可以完全绕过传输层上的TCP和UDP，直接使用IP (如Linux上的LVS )或直接访问链路层。 例如，tcpdump程序直接与链路层通信。
上图说明了其他协议的名称。ICMP控制消息传递协议IGMP互联网组管理协议3358www.Sina.com/地址解析协议ARP
仔细询问地址、端口号MAC地址和IP地址。 MAC地址是介质访问层使用的地址，也称为物理地址、硬件地址或链路地址，在网络设备制造商制造时写入硬件内部。 MAC地址与网络无关。 也就是说，无论将网卡、集线器、路由器等具有此地址的硬件连接到网络中的哪个位置，都有相同的MAC地址。 这是制造商写在网卡的BIOS上的。 理论上，只要不偷硬件(网卡)，就不能造假。
IP地址后者用于标识通过TCP/IP网络互连的主机和路由器。 IP地址基于逻辑，灵活，不受硬件限制，易于存储。
传输层也有这样一个类似地址的概念。 那是端口号。 端口号用于标识在同一台计算机上通信的不同APP应用程序。 因此，也称为程序地址。
一台计算机可以同时运行多个程序。 传输层协议使用这些端口号来标识本地正在通信的APP应用程序，并准确地传输数据。
的端口号决定标准规定的端口号。 这种方法也称为静态方法。 这是为每个APP应用程序指定的端口号。 但是，并不是每个端口号都可以自由使用。 例如，广泛使用的APP应用协议(如HTTP、FTP和TELNET )所使用的端口号是固定的。 这些端口号被称为有名的端口号，分布在0~1023之间； 除了有名的端口号外，还有几个端口号已经正式注册，它们分布在1024
~49151 之间，不过这些端口号可用于任何通信用途。时序分配法：服务器有必要确定监听端口号，但是接受服务的客户端没 必要确定端口号。在这种方法下，客户端应用程序完全可以不用自己设置端口号， 而全权交给操作系统进行分配。动态分配的端口号范围在 49152~65535 之间。 端口号与协议 端口号由其使用的传输层协议决定。因此，不同的传输层协议可以使用 相同的端口号。此外，那些知名端口号与传输层协议并无关系。只要端口一致都将分配 同一种应用程序进行处理。 TCP/IPTCP 是面向连接的通信协议，通过三次握手建立连接，通讯完成时要拆除连 接，由于 TCP 是面向连接的所以只能用于端到端的通讯。
TCP 提供的是一种可靠的数据流服务，采用“带重传的肯定确认”技术来实现 传输的可靠性。TCP 还采用一种称为“滑动窗口”的方式进行流量控制，所谓窗口 实际表示接收能力，用以限制发送方的发送速度。
如果 IP 数据包中有已经封好的 TCP 数据包，那么 IP 将把它们向‘上’传送到 TCP 层。TCP 将包排序并进行错误检查，同时实现虚电路间的连接。TCP 数据包 中包括序号和确认，所以未按照顺序收到的包可以被排序，而损坏的包可以被重 传。
TCP将它的信息送到更高层的应用程序，例如 Telnet 的服务程序和客户程序。 应用程序轮流将信息送回 TCP 层，TCP 层便将它们向下传送到 IP 层，设备驱动程 序和物理介质，最后到接收方。
面向连接的服务（例如 Telnet、FTP、rlogin、X Windows 和 SMTP）需要高度 的可靠性，所以它们使用了 TCP。DNS 在某些情况下使用 TCP（发送和接收域名 数据库），但使用 UDP 传送有关单个主机的信息。
TCP 三次握手
TCP 提供面向有连接的通信传输。面向有连接是指在数据通信开始之前先做 好两端之间的准备工作。
所谓三次握手是指建立一个 TCP 连接时需要客户端和服务器端总共发送三 个包以确认连接的建立。在 socket 编程中，这一过程由客户端执行 connect 来触 发。
第一次握手：客户端将标志位 SYN 置为 1，随机产生一个值 seq=J，并将该 数据包发送给服务器端，客户端进入 SYN_SENT 状态，等待服务器端确认。
第二次握手：服务器端收到数据包后由标志位 SYN=1 知道客户端请求建立连 接，服务器端将标志位 SYN 和 ACK 都置为 1，ack=J+1，随机产生一个值 seq=K， 并将该数据包发送给客户端以确认连接请求，服务器端进入 SYN_RCVD 状态。
第三次握手：客户端收到确认后，检查 ack 是否为 J+1，ACK 是否为 1，如果 正确则将标志位 ACK 置为 1，ack=K+1，并将该数据包发送给服务器端，服务器 端检查 ack 是否为 K+1，ACK 是否为 1，如果正确则连接建立成功，客户端和服 务器端进入 ESTABLISHED 状态，完成三次握手，随后客户端与服务器端之间可以 开始传输数据了。
TCP 的三次握手的漏洞但是在 TCP 三次握手中是有一个缺陷的，就是如果我们利用三次握手的缺陷 进行攻击。这个攻击就是 SYN 洪泛攻击。三次握手中有一个第二次握手，服务端 向客户端应道请求，应答请求是需要客户端 IP 的，服务端是需要知道客户端 IP 的，攻击者就伪造这个 IP，往服务器端狂发送第一次握手的内容，当然第一次握 手中的客户端 IP 地址是伪造的，从而服务端忙于进行第二次握手但是第二次握 手当然没有结果，所以导致服务器端被拖累，死机。
当然我们的生活中也有可能有这种例子，一个家境一般的 IT 男去表白他的 女神被拒绝了，理由是他家里没矿，IT 男为了报复，采用了洪泛攻击，他请了很 多人伪装成qpdqc去表白那位追求矿的女神，让女生每次想交往时发现表白的人 不见了同时还联系不上了。
面对这种攻击，有以下的解决方案，最好的方案是防火墙。
无效连接监视释放
这种方法不停监视所有的连接，包括三次握手的，还有握手一次的，反正是 所有的，当达到一定(与)阈值时拆除这些连接，从而释放系统资源。这种方法对 于所有的连接一视同仁，不管是正常的还是攻击的，所以这种方式不推荐
延缓 TCB 分配方法
一般的做完第一次握手之后，服务器就需要为该请求分配一个 TCB（连接控 制资源），通常这个资源需要 200 多个字节。延迟 TCB 的分配，当正常连接建 立起来后再分配 TCB 则可以有效地减轻服务器资源的消耗。
使用防火墙
防火墙在确认了连接的有效性后，才向内部的服务器（Listener）发起 SYN 请求
四次挥手即终止 TCP 连接，就是指断开一个 TCP 连接时，需要客户端和服务 端总共发送 4 个包以确认连接的断开。在 socket 编程中，这一过程由客户端或 服务端任一方执行 close 来触发。
由于 TCP 连接是全双工的，因此，每个方向都必须要单独进行关闭，这一原 则是当一方完成数据发送任务后，发送一个 FIN 来终止这一方向的连接，收到一 个 FIN 只是意味着这一方向上没有数据流动了，即不会再收到数据了，但是在这 个 TCP 连接上仍然能够发送数据，直到这一方向也发送了 FIN。首先进行关闭的 一方将执行主动关闭，而另一方则执行被动关闭。
服务器只要收到了客户端发出的确认，立即进入 CLOSED 状态。同样，撤销 TCB 后，就结束了这次的 TCP 连接。可以看到，服务器结束 TCP 连接的时间要比 客户端早一些。