如果对象需要根据自身当前状态进行不同行为， 同时状态的数量非常多且与状态相关的代码会频繁变更的话， 可使用状态模式。如果某个类需要根据成员变量的当前值改变自身行为，从而需要使用大量的条件语句时，可使用该模式。状态模式很好的遵守了单一职责原则和开闭原则。将与特定状态相关的代码放在单独的类中，并且无需修改已有状态类和上下文就能引入新状态。通过消除臃肿的状态机条件语句简化上下文代码。

在TCP/IP协议中，传输层有两个重要的协议：TCP和UDP。TCP用于提供可靠的数据传输，而UDP则适合用于广播或对细节控制要求不高的应用传输。为了确保传输层协议能够正确地将接收到的数据交给相应的应用程序，TCP和UDP都引入了的概念，用来识别目标应用。

命令行和sheill这两个概念常常是令人困惑的，在很多不正式的场合，这两个名词代表着相同的概念，即命令行解释器。然而从严格意义上讲，命令行指的是供用户输入命令的界面，其本质只是接受输入，然后把命令传递给命令解释器。后者就是shell。从本质上讲，shell是一个程序，它在用户和操作系统之间提供了一个面向行的可交互接口。用户在命令行中输入命令，运行在后台的Shell把命令转换成指令代码发送操作系统。

观察者设计模式也叫作发布-订阅（）模式，如果用最通俗易懂的语言来描述，应该是这样：观察者（Fighter子类）提供一个特定的成员函数（），并把自已加人到通知器（Notifier子类）的一个对象列表中（订阅/注册），当通知器意识到有事件发生的时候，通过遍历对象列表找到每个观察者并调用观察者提供的特定成员函数（发布）来达到通知观察者某个事件到来的目的。观察者可以在特定的成员函数（）中编写实现代码来实现

简单工厂、工厂方法和抽象工厂是三种常见的创建型设计模式，它们各自有不同的特点和应用场景。代码实现复杂度上，简单工厂模式最简单，工厂方法模式次之，抽象工厂模式最复杂。简单工厂模式中的代码修改得符合开闭原则，就变成了工厂方法模式，修改工厂方法模式的代码使一个工厂支持对多个具体产品的生产，就变成了抽象工厂模式。从需要的工厂数量上。

TCP 旨在构建在 IP 层之上的一种稳定的数据传输服务。IP层虽然能够将数据包从一端传输到另一端，但其服务性质是尽力而为，不保证数据的可靠到达。TCP的设计目标是在这样的基础上，提供一种确保数据完整性和顺序性的传输机制。也就是说，TCP 提供可靠数据传输服务保证接收方进程从缓冲区读出的字节数与发送方发出的字节流完全一样。TCP 使用了校验、序号、确认和重传等机制来达到这一目的。

当某个IP包到达路由器时，路由器首先查找其目标地址（IP包被转发到途中的某个路由器时，实际上是装入数据链路层的数据帧以后再被送出），从而再决定下一步应该这个数据包到达哪个路由器，然后再把包发送过去。因此，IP 层进行分片传输是很没有效率的。在进行 NAT 转换时，路由器会将源 IP 地址和端口号替换为它自己的公网 IP 地址+端口号，并在其 NAPT 转换表中记录转换信息，以便在接收到响应数据包时

TCP与UDP的区别相当大。它充分地实现了数据传输时各种控制功能，可以进行丢包时的重发控制，还可以对次序乱掉的分包进行顺序控制。而这些在UDP中都没有。此外，TCP作为一种面向有连接的协议，只有在确认通信对端存在时才会发送数据，从而可以控制通信流量的浪费（由于UDP没有连接控制，所以即使对端从一开始就不存在或中途退出网络，数据包还是能够发送出去。（当ICMP错误返回时，有时也实现了不再发送的机制。

在使用UDP的情况下，虽然可以确保发送消息的大小（例如，发送端应用程序发送一个100字节的消息，那么接收端应用程序也会以100字节为长度接收数据。这样，在进程能够读该套接字中任何已排好队的数据报之前，如果有多个数据到达该套接字，那么相继到达的数据报仅仅加到该套接字的接收缓冲区中。在UDP中，每个数据报文（数据报）都是独立的，不依赖于前后的数据报。：由UDP给某个特定套接字排队的UDP数据报的数目受

在OSI的七层模型结构中，从纵向即单个主机的角度来看，每一层与本层的上下两层从逻辑上是分开的，即A的网络层和数据链路层是分开的。这种方式使得每层为上一层提供服务，依赖于下层的数据并为上一层提供接口。同时各层之间的规则是相互独立的，例如数据的格式、通信的方式，这成为本层的协议。