1. 计算机网络都是怎样运行的
鉴于计算机网络规模巨大、联系面广、涉及因素多，通常要划分成各种特定问题，突出主要因素、忽略或弱化次要因素，并进行概括、抽象，建立典型化模型来加以研究
组建计算机网络时，首先要解决的具体问题和理论问题。目的是在满足应用需求和客观约束条件下，以最少的投入（包括人力 、物力、财力、时间等)，设计、建造一个安全、可靠 、有效、运行良好 、适应性强、易管理、易维护、易改造、易扩充的计算机网络，并预计回答资金回收期限以及可能获得的最大的社会效益和经济效益等问题。优化设计分为 3个阶段 ：① 需求分析与规划阶段。应对需求和环境进行调查 ，收集 、整理必要的资料与数据，包括应用目的、信息格式、通信量、响应时间、差错率、可靠性要求、选用的标准，以及现有设备、用户分布、地理环境、自然条件 、气象特征、外界影响等 ，目的是明确需求、找出关键环节、规划项目的总体轮廓。②网络总体设计阶段。在调查分析的基础上，应根据应用需求，确定网络的总体框架和重要的网络参数，必须对一些重要的关键问题做出抉择，如选用何种拓扑结构，设备的选型、安置和连接方法，通信介质的选择、线路布局和容量分配，通信规程以及路由、流量和差错控制技术，网络业务的种类、服务质量及高层协议的选择等。③设计方案评测阶段。根据评测目标。建立各种数学模型（如预测模型、优化模型、性能评价模型等），以便对网络的性能、费用、工期时限、效益概算、资金回收期限等进行分析与评价，给出技术与经济可行性结论。如果结论达不到预计要求，应视情况，部分或全部进行重新网络优化设计。
网络体系结构编辑
计算机网络体系结构是一组用于规划、设计、组建计算机网络所需遵循的原则和依据，包括层次结构、功能划分、协议规范、过程描述等内容。对计算机网络发展最有影响的网络体系结构是国际标准化组织（ISO）建议的开放系统互连（OSI）参考模型 。它是通过体系模型、服务定义和协议规范3 个抽象级别，逐步深入、逐步细化加以制定和描述的。体系结构模型是OSI 最高级别的抽象，它从功能和概念级上建造了一个抽象的、具有层次结构的体系模型，刻画了开放系统的整体性能 、结构要素 、行为特征、层次关系 、数据格式等内容 。OSI 体系结构模型由应用层、表示层、会话层、运输层、网络层、数据链路层和物理层等7层组成。服务定义是OSI低一级别的抽象，它更详细地定义每层提供的服务，规定各层的外特性和层间抽象接口，但不涉及是否实现和如何实现的细节。协议规范是 OSI最低级别的抽象，它精确地定义某层实体为了协同工作和交互活动所需传送控制信息的语义和语法，以及采用什么样的规程去分析、解释和加工它们。体系结构模型进一步发展趋向是研究、制定网络应用体系结构模型，目的是为网络用户创造良好的运行环境和开发环境。例如，一些网络专家在 OSI模型的基础上，提出开放应用体系结构（OAA）模型的设想。OAA由操作环境和开发维护环境两部分组成。
路径选择编辑
早期计算机领域中几个热门研究课题，成果多、文献量大。路径选择的主要目的是在网络中选择最佳路径 ，将源站点发送的报文信息高速、有效地传送到目的站点，其侧重点是提高网络服务质量、减少延迟时间、降低传输费用。衡量路径选择算法好坏的标准包括：①报文信息以最短的时间、最短的路径或最少的费用，传送到目的地。②算法简单、易于实现、适应性强（能适应网络故障和结构变化所带来的影响）。③不过重增加网络和结点的开销（包括处理机时间、存储容量 、信息传输量等)。④有助于改善网络性能、保持稳定的吞吐率、降低平均传输延迟时间、均衡网络负载等。典型路径选择算法有扩散式路径选择、随机式路径选择、固定路径选择、自适应路径选择等。
控制内容编辑
流量控制和拥挤控制
流量控制和拥挤控制的目的是控制网络和各条通信线路上的信息流通量，保持网络处于稳定的工作状态，以便提高网络吞吐率、减少平均延迟时间，其侧重点是改善网络工作效率和资源利用率，防止拥塞和死锁现象发生。流量控制可分为相邻结点间流控、源结点与目的结点间流控、主机与结点间流控、主机与主机间流控四种类型。常用的控制方法有限定传输速率、拒收重传、暂停发送、限定接收发送窗口大小、预约缓冲区等。用于拥挤控制的方法有预约缓冲区、限制管道流量、入网许可证、反向抑制等。
差错控制
也是网络设计中的重要研究课题，其目的是根据应用要求、线路质量、设备性能和外界环境等因素，选择适当的控制机制和方法，查出并纠正信息传输中的差错，将其减少到允许程度之内。计算机网络中，通常采用两种基本策略来处理信息传输中的差错：①使用纠错码。即在要发送的信息报文中附加上足够多的冗余信息，使接收方不仅能够查出、而且能够纠正信息报文中的差错。因信息冗余量过大，且控制复杂，通常用于单向传输场合，或用作辅助措施。②使用检错码。即在要发送的信息报文中附加一定的冗余信息，使接收方能够查出信息报文中的差错（但不知什么样的差错），并通知发送方重传原来的信息报文。通信规程和网络协议通常采用这种方法。
协议工程编辑
计算机网络领域中最活跃的研究课题之一 ，目的是把软件工程的原理和方法用于计算机网络协议的描述、实现和验证工作 。协议工程的主要研究内容包括3 个方面：①协议形式化描述及其形式化描述语言。②协议软件的自动生成技术及其开发维护工具。③协议一致性测试技术及其测试工具 。协议工程的研究有助于加深理解计算机网络协议，有助于提高协议软件的生产效率，有助于改善网络协议软件的维护管理水平。但是，协议工程与软件工程相比，无论在研究、开发、应用的深度和广度上说，均有距离，尚有广阔的开拓、发展前景。
2. 计算机软件系统的组成部分有哪些
软件系统由系统软件、支撑软件和应用软件组成，构成计算机系统的软件部分。
操作系统负责管理计算机资源，调控程序运行。语言处理系统处理编程语言，如编译程序等。数据库系统支持数据管理和存取，包含数据库、数据库管理系统等。数据库为计算机系统内驻留的数据集合，通过数据模式定义它们间的关系，以数据定义语言描述。数据库管理系统允许用户以抽象方式存取、利用和修改数据。
分布式软件系统包括分布式操作系统、程序设计系统、文件系统、数据库系统等，提供跨多个计算机网络的软件服务。
人机交互系统是用户与计算机系统信息交换的软件，提供友好界面，实现约定的交互约定。
操作系统功能包括处理器管理、存储管理、文件管理、设备管理和作业管理。主要研究内容涵盖操作系统结构、进程调度、同步机制、死锁预防、内存分配、设备分配、并行机制、容错和恢复机制。
3. 怎么避免死锁
什么是死锁，如何避免死锁？
线程A需要资源X，而线程B需要资源Y，而双方都掌握有对方所要的资源，这种情况称为死锁（deadlock），或死亡拥抱（the deadly embrace）。
在并发程序设计中，死锁 (deadlock) 是一种十分常见的逻辑错误。通过采用正确的编程方式，死锁的发生不难避免。
死锁的四个必要条件
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
在计算机专业的本科教材中，通常都会介绍死锁的四个必要条件。这四个条件缺一不可，或者说只要破坏了其中任何一个条件，死锁就不可能发生。我们来复习一下，这四个条件是：
互斥（Mutual exclusion）：存在这样一种资源，它在某个时刻只能被分配给一个执行绪（也称为线程）使用；
持有（Hold and wait）：当请求的资源已被占用从而导致执行绪阻塞时，资源占用者不但无需释放该资源，而且还可以继续请求更多资源；
不可剥夺（No preemption）：执行绪获得到的互斥资源不可被强行剥夺，换句话说，只有资源占用者自己才能释放资源；
环形等待（Circular wait）：若干执行绪以不同的次序获取互斥资源，从而形成环形等待的局面，想象在由多个执行绪组成的环形链中，每个执行绪都在等待下一个执行绪释放它持有的资源。
解除死锁的必要条件
不难看出，在死锁的四个必要条件中，第二、三和四项条件比较容易消除。通过引入事务机制，往往可以消除第二、三两项条件，方法是将所有上锁操作均作为事务对待，一旦开始上锁，即确保全部操作均可回退，同时通过锁管理器检测死锁，并剥夺资源（回退事务）。这种做法有时会造成较大开销，而且也需要对上锁模式进行较多改动。
消除第四项条件是比较容易且代价较低的办法。具体来说这种方法约定：上锁的顺序必须一致。具体来说，我们人为地给锁指定一种类似“水位”的方向性属性。无论已持有任何锁，该执行绪所有的上锁操作，必须按照一致的先后顺序从低到高（或从高到低）进行，且在一个系统中，只允许使用一种先后次序。
请注意，放锁的顺序并不会导致死锁。也就是说，尽管按照 锁A, 锁B, 放A, 放B 这样的顺序来进行锁操作看上去有些怪异，但是只要大家都按先A后B的顺序上锁，便不会导致死锁。
解决方法：
1 使用事务时，尽量缩短事务的逻辑处理过程，及早提交或回滚事务； (细化处理逻辑，执行一段逻辑后便回滚或者提交，然后再执行其它逻辑，直到事物执行完毕提交)
2 设置死锁超时参数为合理范围，如：3分钟-10分种；超过时间，自动放弃本次操作，避免进程悬挂；
3 优化程序，检查并避免死锁现象出现；
4 .对所有的脚本和SP都要仔细测试，在正是版本之前。
5 所有的SP都要有错误处理（通过@error）
6 一般不要修改SQL SERVER事务的默认级别。不推荐强行加锁
另外参考的解决方法：
按同一顺序访问对象
如果所有并发事务按同一顺序访问对象，则发生死锁的可能性会降低。例如，如果两个并发事务获得 Supplier 表上的锁，然后获得 Part 表上的锁，则在其中一个事务完成之前，另一个事务被阻塞在 Supplier 表上。第一个事务提交或回滚后，第二个事务继续进行。不发生死锁。将存储过程用于所有的数据修改可以标准化访问对象的顺序。
避免事务中的用户交互
避免编写包含用户交互的事务，因为运行没有用户交互的批处理的速度要远远快于用户手动响应查询的速度，例如答复应用程序请求参数的提示。例如，如果事务正在等待用户输入，而用户去吃午餐了或者甚至回家过周末了，则用户将此事务挂起使之不能完成。这样将降低系统的吞吐量，因为事务持有的任何锁只有在事务提交或回滚时才会释放。即使不出现死锁的情况，访问同一资源的其它事务也会被阻塞，等待该事务完成。
保持事务简短并在一个批处理中
在同一数据库中并发执行多个需要长时间运行的事务时通常发生死锁。事务运行时间越长，其持有排它锁或更新锁的时间也就越长，从而堵塞了其它活动并可能导致死锁。保持事务在一个批处理中，可以最小化事务的网络通信往返量，减少完成事务可能的延迟并释放锁。
使用低隔离级别
确定事务是否能在更低的隔离级别上运行。执行提交读允许事务读取另一个事务已读取（未修改）的数据，而不必等待第一个事务完成。使用较低的隔离级别（例如提交读）而不使用较高的隔离级别（例如可串行读）可以缩短持有共享锁的时间，从而降低了锁定争夺。
使用绑定连接
使用绑定连接使同一应用程序所打开的两个或多个连接可以相互合作。次级连接所获得的任何锁可以象由主连接获得的锁那样持有，反之亦然，因此不会相互阻塞。
4. 计算机网络——TCP/UDP协议
计算机网络七层模型中，传输层有两个重要的协议：
（1）用户数据报协议UDP (User Datagram Protocol)
（2）传输控制协议TCP (Transmission Control Protocol)
UDP 在传送数据之前不需要先建立连接。远地主机的运输层在收到UDP 报文后，不需要给出任何确认。虽然UDP 不提供可靠交付，但在某些情况下UDP 却是一种最有效的工作方式。
TCP 则提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。TCP 不提供广播或多播服务。由于TCP 要提供可靠的、面向连接的运输服务，因此不可避免地增加了许多的开销，如确认、流量控制、计时器以及连接管理等。
UDP 的主要特点是：
首部手段很简单，只有8 个字节，由四个字段组成，每个字段的长度都是两个字节。
前面已经讲过，每条TCP 连接有两个端点，TCP 连接的端点叫做套接字（socket）或插口。套接字格式如下：
套接宁socket= (IP 地址：端口号’）
每一条TCP 连接唯一地被通信两端的两个端点（即两个套接宇）所确定。即：
TCP 连接＝ {socket1, socket2} = {(IP1: port1), (IP2: port2)}
3次握手链接
4次握手释放链接
断开连接请求可以由客户端发出，也可以由服务器端发出，在这里我们称A端向B端请求断开连接。
各个状态节点解释如下：
下面为了讨论问题的万便，我们仅考虑A发送数据而B 接收数据并发送确认。因此A 叫做发送方，而B 叫做接收方。
“停止等待”就是每发送完一个分组就停止发送，等待对方的确认。在收到确认后再发送下一个分组。
使用上述的确认和重传机制，我们就可以在不可靠的传输网络上实现可靠的通信。像上述的这种可靠传输协议常称为自动重传请求ARQ (Automatic Repeat reQuest）。意思是重传的请求是自动进行的。接收方不需要请求发送方重传某个出错的分组。
滑动窗口协议比较复杂，是TCP 协议的精髓所在。这里先给出连续ARQ 协议最基本的概念，但不涉提到许多细节问题。详细的滑动窗口协议将在后面讨论。
下图表示发送方维持的发送窗口，它的意义是：位于发送窗口内的5 个分组都可连续发送出去，而不需要等待对方的确认。这样，信道利用率就提高了。
连续ARQ 协议规定，发送方每收到一个确认，就把发送窗口向前滑动一个分组的位置。
接收方一般都是采用 累积确认 的方式。这就是说，接收方不必对收到的分组逐个发送确认，而是可以在收到几个分组后，对按序到达的最后一个分组发送确认，这样就表示：到这个分组为止的所有分组都己正确收到了。
累积确认 的优点是容易实现，即使确认丢失也不必重传。但缺点是不能向发送方反映出接收方己经正确收到的所有分组的信息。
例如，如果发送方发送了前5 个分组，而中间的第3 个分组丢失了。这时接收方只能对前两个分组发出确认。发送方无法知道后面三个分组的下落，而只好把后面的三个分组都再重传一次。这就叫做Go-back-N （回退N ），表示需要再退回来重传己发送过的N 个分组。可见当通信线路质量不好时，连续ARQ 协议会带来负面的影响。
TCP 的滑动窗口是以字节为单位的。现假定A 收到了B 发来的确认报文段，其中窗口是20 （字节），而确认号是31 （这表明B 期望收到的下一个序号是31 ，而序号30 为止的数据己经收到了）。根据这两个数据， A 就构造出自己的发送窗口，其位置如图所示。
发送窗口表示：在没有收到B 的确认的情况下， A可以连续把窗口内的数据都发送出去。凡是己经发送过的数据，在未收到确认之前都必须暂时保留，以便在超时重传时使用。
发送窗口后沿的后面部分表示己发送且己收到了确认。这些数据显然不需要再保留了。而发送窗口前沿的前面部分表示不允许发送的，因为接收方都没有为这部分数据保留临时存放的缓存空间。
现在假定A 发送了序号为31 ～ 41 的数据。这时发送窗口位置并未改变，但发送窗口内靠后面有11个字节（灰色小方框表示）表示己发送但未收到确认。而发送窗口内靠前面的9 个字节（ 42 ～ 50 ）是允许发送但尚未发送的。】
再看一下B 的接收窗口。B 的接收窗口大小是20，在接收窗口外面，到30 号为止的数据是已经发送过确认，并且己经交付给主机了。因此在B 可以不再保留这些数据。接收窗口内的序号（31～50）足允许接收的。B 收到了序号为32 和33 的数据，这些数据没有按序到达，因为序号为31 的数据没有收到（也许丢失了，也许滞留在网络中的某处）。 请注意， B 只能对按序收到的数据中的最高序号给出确认，因此B 发送的确认报文段中的确认号仍然是31 （即期望收到的序号）。
现在假定B 收到了序号为31 的数据，并把序号为31～33的数据交付给主机，然后B删除这些数据。接着把接收窗口向前移动3个序号，同时给A 发送确认，其中窗口值仍为20，但确认号是34，这表明B 已经收到了到序号33 为止的数据。我们注意到，B还收到了序号为37, 38 和40 的数据，但这些都没有按序到达，只能先存在接收窗口。A收到B的确认后，就可以把发送窗口向前滑动3个序号，指针P2 不动。可以看出，现在A 的可用窗口增大了，可发送的序号范围是42～53。整个过程如下图：
A 在继续发送完序号42-53的数据后，指针P2向前移动和P3重合。发送窗口内的序号都已用完，但还没有再收到确认。由于A 的发送窗口己满，可用窗口己减小到0，因此必须停止发送。
上面已经讲到， TCP 的发送方在规定的时间内没有收到确认就要重传已发送的报文段。这种重传的概念是很简单的，但重传时间的选择却是TCP 最复杂的问题之一。
TCP采用了一种自适应算法 ，它记录一个报文段发出的时间，以及收到相应的确认的时间。这两个时间之差就是报文段的往返时间RTT，TCP 保留了RTT的一个加权平均往返时间RTTs （这又称为平滑的往返时间， S 表示Smoothed 。因为进行的是加权平均，因此得出的结果更加平滑）。每当第一次测量到RTT样本时， RTTs值就取为所测量到的RTT样本值。但以后每测量到一个新的RTT样本，就按下式重新计算一次RTTs:
新的RTTs = (1 － α）×（旧的RTTs) ＋ α ×（新的RTT样本）
α 越大表示新的RTTs受新的RTT样本的影响越大。推荐的α 值为0.125，用这种方法得出的加权平均往返时间RTTs 就比测量出的RTT值更加平滑。
显然，超时计时器设置的超时重传时间RTO (RetransmissionTime-Out）应略大于上面得出的加权平均往返时间RTTs。RFC 2988 建议使用下式计算RTO:
RTO = RTTs + 4 × RTTd
RTTd是RTT 的偏差的加权平均值，它与RTTs和新的RTT样本之差有关。计算公式如下：
新的RTTd= (1- β）×（旧的RTTd) + β × |RTTs－新的RTT样本|
发现问题： 如图所示，发送出一个报文段。设定的重传时间到了，还没有收到确认。于是重
传报文段。经过了一段时间后，收到了确认报文段。现在的问题是：如何判定此确认报文段是对先发送的报文段的确认，还是对后来重传的报文段的确认？
若收到的确认是对重传报文段的确认，但却被源主机当成是对原来的报文段的确认，则这样计算出的RTTs 和超时重传时间RTO 就会偏大。若后面再发送的报文段又是经过重传后才收到确认报文段，则按此方法得出的超时重传时间RTO 就越来越长。
若收到的确认是对原来的报文段的确认，但被当成是对重传报文段的确认，则由此计算出的RTTs 和RTO 都会偏小。这就必然导致报文段过多地重传。这样就有可能使RTO 越来越短。
Kam 提出了一个算法：在计算加权平均RTTs 时，只要报文段重传了就不采用其往返时间样本。这样得出的加权平均RTTs 和RTO 就较准确。
新问题： 设想出现这样的情况：报文段的时延突然增大了很多。因此在原来得出的重传时间内，不会收到确认报文段。于是就重传报文段。但根据Kam 算法，不考虑重传的报文段的往返时间样本。这样，超时重传时间就无法更新。
解决方案： 对Kam 算法进行修正，方法是z报文段每重传一次，就把超时重传时间RTO 增大一些。典型的做法是取新的重传时间为2 倍的旧的重传时间。当不再发生报文段的重传时，才根据上面给出的公式计算超时重传时间。
流量控制（flow control）就是让发送方的发送速率不要太快，要让接收方来得及接收。
利用滑动窗口机制可以很方便地在TCP 连接上实现对发送方的流量控制。
接收方的主机B 进行了三次流量控制。第一次把窗口减小到rwnd =300，第二次又减到rwnd = 100 ，最后减到rwnd = 0 ，即不允许发送方再发送数据了。这种使发送方暂停发送的状态将持续到主机B 重新发出一个新的窗口值为止。我们还应注意到，B 向A 发送的三个报文段都设置了ACK=1，只有在ACK=1 时确认号字段才有意义。
发生死锁： 现在我们考虑一种情况。上图中， B 向A 发送了零窗口的报文段后不久， B 的接收缓存又有了一些存储空间。于是B 向A 发送了rwnd = 400 的报文段。然而这个报文段在传送过程中丢失了。A 一直等待收到B 发送的非零窗口的通知，而B 也一直等待A 发送的数据。如果没有其他措施，这种互相等待的死锁局面将一直延续下去。
解决方案： TCP 为每一个连接设有一个 持续计时器（persistence timer） 。只要TCP 连接的一方收到对方的零窗口通知，就启动持续计时器。若持续计时器设置的时间到期，就发送一个 零窗口探测报文段 （仅携带1 宇节的数据），而对方就在确认这个探测报文段时给出了现在的窗口值。
1 TCP连接时是三次握手，那么两次握手可行吗？
在《计算机网络》中是这样解释的：已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送ACK包。这样就会白白浪费资源。而经过三次握手，客户端和服务器都有应有答，这样可以确保TCP正确连接。
2 为什么TCP连接是三次，挥手确是四次？
在TCP连接中，服务器端的SYN和ACK向客户端发送是一次性发送的，而在断开连接的过程中，B端向A端发送的ACK和FIN是是分两次发送的。因为在B端接收到A端的FIN后，B端可能还有数据要传输，所以先发送ACK，等B端处理完自己的事情后就可以发送FIN断开连接了。
3 为什么在第四次挥手后会有2个MSL的延时？
MSL是Maximum Segment Lifetime，最大报文段生存时间，2个MSL是报文段发送和接收的最长时间。假定网络不可靠，那么第四次发送的ACK可能丢失，即B端无法收到这个ACK，如果B端收不到这个确认ACK，B端会定时向A端重复发送FIN，直到B端收到A的确认ACK。所以这个2MSL就是用来处理这个可能丢失的ACK的。
1 文件传送协议
文件传送协议FTP (File Transfer Protocol) [RFC 959］是因特网上使用得最广泛的文件传送协议，底层采用TCP协议。
盯P 使用客户服务器方式。一个FTP 服务器进程可同时为多个客户进程提供服务。FTP的服务器进程由两大部分组成：一个主进程，负责接受新的请求：另外有若干个从属进程，负责处理单个请求。
在进行文件传输时，客户和服务器之间要建立两个并行的TCP 连接：“控制连接”（21端口）和“数据连接”（22端口）。控制连接在整个会话期间一直保持打开， FTP 客户所发出的传送请求，通过控制连接发送给服务器端的控制进程，但控制连接并不用来传送文件。实际用于传输文件的是“数据连接”。服务器端的控制进程在接收到FTP 客户发送来的文件传输请求后就创建“数据传送进程”和“数据连接”，用来连接客户端和服务器端的数据传送进程。
2 简单文件传送协议TFTP
TCP/IP 协议族中还有一个简单文件传送协议TFfP (Trivial File Transfer Protocol），它是一个很小且易于实现的文件传送协议，端口号69。
TFfP 也使用客户服务器方式，但它使用UDP 数据报，因此TFfP 需要有自己的差错改正措施。TFfP 只支持文件传输而不支持交耳。
3 TELNET
TELNET 是一个简单的远程终端协议，底层采用TCP协议。TELNET 也使用客户服务器方式。在本地系统运行TELNET 客户进程，而在远地主机则运行TELNET 服务器进程，占用端口23。
4 邮件传输协议
一个电子邮件系统应具如图所示的三个主要组成构件，这就是用户代理、邮件服务器，以及邮件发送协议（如SMTP ）和邮件读取协议（如POP3)， POP3 是邮局协议（Post Office Protocol）的版本3 。
SMTP 和POP3 （或IMAP ）都是在TCP 连接的上面传送邮件，使用TCP 的目的是为了使邮件的传送成为可靠的。
5. 常见网络故障与无线局域网问题详解
常见网络故障与无线局域网问题详解
因为互联网的普及，在庞大用户数量的背后，随着而来的是各种人为的、非人为的网络故障。为什么我能上QQ却不能上网?为什么淘宝又打不开了?为什么访问谷歌老是断线?在种种疑问的背后，你是否曾经想过，到底是谁动了我的网络?下面由我带来常见网络故障与无线局域网问题详解。
一、网络故障
1、网卡正确安装但重启时报错
这说明网卡根本没有检测到，或者在软、硬件上配置有误。可以从以下几个方面来查：
1)、确保所用网卡被该操作系统支持。
2)、确保使用了正确的网卡驱动程序。
3)、用网卡所带的设置程序正确设置其IRQ，I/O address，RAM address，网 线类型等。有跳线的要确保跳线正确。对于新的网卡，只要进入EISA 、PCI 设 置程序，使其设为自动检测。
4)、用"hwconfig -hc" 可以检测出配置中的冲突。在系统引导时也可以发现 类似"card not found" ，"unable to start"的错误。这说明软件配置同硬件 有冲突。
5)、网卡配置后，重连内核，重启。
6)、可以用ping 或 netstat 来检查资源冲突。先ping 一局域网结点，再用："netstat -i"来看其收发包情况，如果Ipkts 增大，但Opkts 为 0，那么I/O address 错; 如果Opkts 增大，但Ipkts 为0， 则为IRQ 错。
2、网卡正常检测，但不能与其它电脑实现互连
这主要是由于网络掩码或广播地址配置错、网线不通、网络协议不对、路由不对、网络 速度不匹配、网络程序包文件不完整等。
1)、首先用ping localhost、IP，若通，则说明本机TCP/IP工作正常;若不 通，则需重配重启。再不行， 可用"fiWindows XPerm"来检查网络程序包的完整性。重配 后请删除"/etc/hosts"中多余的记录。
2)、用"ifconfig -a”检查其它工作正常的局域网机器及其本身，应确保其网络掩码及广播地址一致(下划线部分)。
例：#ifconfig -a
net0： flags=4043 mtu 1500 inet 164.230.
120.27 netmask ffff0000 broadcast 164.230.255.255 perf. params：
recv size： 24576; send size： 24576; full-size frames： 1
ether 00：80：5f：70：b2：f5
lo0： flags=4049mtu 8232 inet 127.0.0.1
netmask ff000000 perf. params： recv size： 57344; send size： 57344;
full-size frames： 1
如果网络掩码及广播地址与其它机器一样，你可以用"arp -a" 发现其它机器的物理地址。若不能发现则可能因为是网线不通或网络掩码及广播地址配置不对。例：
# ping 164.230.1.10
Pinging 164.230.1.10 with 32 bytes of data：
Reply form 164.230.1.10 ： bytes=32 time=5ms TTL=255
Reply form 164.230.1.10 ： bytes=32 time=3ms TTL=255
.......
# arp -a
Internet Address Physical Address Type
164.230.1.10 00-06-29-ee-33-37 dynamic
3)、用"netstat -i"检查Ipkts和 Opkts在ping前后的变化情况，如果二者均没有增加，则说明网卡没有包交换，需要更换可靠网线(其它工作正常机器上的)。
4)、有些网卡缺省设置其速率为100M，也会导致网络不通，需要在根据所连HUB口的 速率，在其高级设置里设置其速率或设成AUTO。
3、电脑只能和部分机器互联
这主要是针对网络间加了路由器的情形。由于不正常的路由、错误的子网分割或对方机器上设有相应的路由。或双方的帧类型不同。可以从以下几点来找出问题。
1)、用"traceroute 目的IP" 来找到包可到的机器A，问题往往出现在A的下一步B上，看看B上有无返回的路由。这样一步一步到达目的IP。
2)、确保子网间的路由正确。
3)、确保同一局域网上机器使用同样的帧类型。如：EthernetII ，802.3，802.5等。
4、网络间歇性地不通、减慢或死锁
这主要是由于一些工作量大的程序，超出系统的负荷造成。这时需要调整内核参数。
1)、有时会出现类似"out of streams"等错误提示。先可以用"netstat -m" 来查看系统运行此程序所需的STREAMS。然后调整它。
2)、过时的驱动程序也会引起网络死锁。这只要及时更新其最新版本即可。
5、网速很慢
这个问题有两种可能，一是网络提供商的原因，另一种就是你机器本身的原因，网络提供商的问题我们这里就不讲了，主要讲一下机器本身的原因。
1)、网线问题
我们知道，双绞线是由四对线按严格的`规定紧密地绞和在一起的，用来减少串扰和背景噪音的影响。同时，在T568A标准和T568B标准中仅使用了双绞线的1、2和3、6四条线，其中，1、2用于发送，3、6用于接收，而且1、2必须来自一个绕对，3、6必须来自一个绕对。只有这样，才能最大限度地避免串扰，保证数据传输。本人在实践中发现不按正确标准(T586A、T586B)制作的网线，存在很大的隐患。表现为：一种情况是刚开始使用时网速就很慢;另一种情况则是开始网速正常，但过了一段时间后，网速变慢。后一种情况在台式电脑上表现非常明显，但用笔记本电脑检查时网速却表现为正常。对于这一问题本人经多年实践发现，因不按正确标准制作的网线引起的网速变慢还同时与网卡的质量有关。一般台式计算机的网卡的性能不如笔记本电脑的，因此，在用交换法排除故障时，使用笔记本电脑检测网速正常并不能排除网线不按标准制作这一问题的存在。我们现在要求一律按T586A、T586B标准来压制网线，在检测故障时不能一律用笔记本电脑来代替台式电脑。
2)、网络中存在回路
当网络涉及的节点数不是很多、结构不是很复杂时，这种现象一般很少发生。但在一些比较复杂的网络中，经常有多余的备用线路，如无意间连上时会构成回路。比如网线从网络中心接到计算机一室，再从计算机一室接到计算机二室。同时从网络中心又有一条备用线路直接连到计算机二室，若这几条线同时接通，则构成回路，数据包会不断发送和校验数据，从而影响整体网速。这种情况查找比较困难。为避免这种情况发生，要求我们在铺设网线时一定养成良好的习惯：网线打上明显的标签，有备用线路的地方要做好记载。当怀疑有此类故障发生时，一般采用分区分段逐步排除的方法。
3)、网络设备硬件故障
作为发现未知设备的主要手段，广播在网络中起着非常重要的作用。然而，随着网络中计算机数量的增多，广播包的数量会急剧增加。当广播包的数量达到30%时，网络的传输效率将会明显下降。当网卡或网络设备损坏后，会不停地发送广播包，从而导致广播风暴，使网络通信陷于瘫痪。因此，当网络设备硬件有故障时也会引起网速变慢。当怀疑有此类故障时，首先可采用置换法替换集线器或交换机来排除集线设备故障。如果这些设备没有故障，关掉集线器或交换机的电源后，DOS下用“Ping”命令对所涉及计算机逐一测试，找到有故障网卡的计算机，更换新的网卡即可恢复网速正常。网卡、集线器以及交换机是最容易出现故障引起网速变慢的设备。
4)、某个端口形成了瓶颈
实际上，路由器广域网端口和局域网端口、交换机端口、集线器端口和服务器网卡等都可能成为网络瓶颈。当网速变慢时，我们可在网络使用高峰时段，利用网管软件查看路由器、交换机、服务器端口的数据流量;也可用Netstat命令统计各个端口的数据流量。据此确认网络数据流通瓶颈的位置，设法增加其带宽。具体方法很多，如更换服务器网卡为1查找计算机，找到其他组的计算机后作成快捷方式放在桌面上。