📄 article711.asp.htm
字号:
<!--<TABLE>
<TR>
<TD>
The Internet, A Summary Introduction to TCP/IP, and Losing Underwear
</TD>
<TD>
See Also:
</TD>
</TR>
<TR>
<TD COLSPAN=2>-->
<P ALIGN="center"><SPAN CLASS="title">The Internet, A Summary Introduction to TCP/IP, and Losing Underwear</SPAN>
<BR><SPAN CLASS="author">by Jered Wierzbicki</SPAN></P>
<P>CONTENTS
<P><B>Relevant Background on the Internet</B>
<P><B>The TCP/IP Suite</B>
<DIR><BR>What's a protocol and how do I use it?
<BR>How are protocols maintained by the Global Internet?
<BR>The TCP Protocol
<BR>The UDP Protocol
<BR>The IP Protocol
<DIR><BR>IP Addresses
<BR>The Domain Name System
<BR>The ICMP Protocol
<BR>The GGP Protocol
<BR>The ARP and RARP Protocols
</DIR></DIR>
<P><B>Physical Protocols and Why we Don't Care</B>
<P><B>TCP/IP Programming</B>
<DIR>Win32 TCP/IP Support: WinSock
<DIR>Initializing the WinSock Library
<BR>Creating Sockets
<BR>Binding and Connecting
<BR>Addressing and Name Service Support
<BR>Network and Host Byte-order
<BR>Sending and Receiving Data
<BR>How to get your sockets to listen()
<BR>Blockage and Synchronicity
<BR>Errors in WinSock
<BR>Cleaning up after yourself
<BR>What I didn't cover
</DIR></DIR>
<P><B>Coda</B>
<P><B>Disclaimers</B>
<H1>Relevant Background on the Internet</H1>
<P>The history of the Internet is vast and vibrant, filled with exciting people, stunning breakthroughs and unbelievable events, intruige, imagination, and all of that great sort of thing. Tens of thousands of pages have been written on its development alone. Obviously, then, it is not my intention to sit and talk to you about the history of this marvel of technology, of this manefestation of our science. I'm just going to present you with enough trinkets to realize that all (well, most, anyway) of its arcane complexity is absolutely vital.
<P>The United States first suggested a communications Internet as a tactical advantage in 1962. Communism was on the rise, tensions were high, and the increasing threat of nuclear warfare was widely perceived. The United States Air Force challenged a select group of R&D people to come up with a network that could withstand a nuclear attack. The network that they envisioned was called a Distributed Communications Network, or a "decentralized" network, which was a theretofore unheard of concept. The idea was simple. If one node was destroyed, the capacity to exchange data had to remain in place. Paul Baran, with the RAND corporation at the time, conceptualized such a network in full detail (FULL detail). Unfortunately, due to a rather breaucratic review of Baran's research, nothing happened until 1969. Finally the time was ripe: Research merged with funding and this with renewed government interest (on behalf of DARPA, Defense Advanced Research Projects Agency), resulting in the birth of the ARPANET.
<P>The ARAPNET gradually grew and expanded in amazing ways not very important to us. It started with four hosts. Four years later, it had 40. With the invention of e-mail in '72, a new surge of data relied on the network. Incredible though it may seem, most of the data sent and received via ARPANET was e-mail at the time. Now keep in mind, in the mid-70's, TCP/IP also came along and fundamentally redefined the way that communications over the network were carried out. By the first few years of the 80's, there were hundreds of hosts. In 1988, there were over 51,000. In 1990, there were well, well over 300,000 hosts. Another milestone in '90: The government gave control of the network to the National Science Foundation (NSF), who subsequently released it to the public domain due to excessive backbone operating and upkeeping costs. Commercial business promptly moved in for the kill.
<P>Well, to make a long story short, a group at the U of Minnesota came up with Gopher, an independent European innovator conceived developed HTML, along with the web browser, and the rest is history. Public recognition of the Internet spread like wildfire. Don't ask me who counts, but the size of the Internet has increased by over 25,000% from 1969 to the present.
<P>To clear up a few misconceptions: The Internet is not one network. It is a set of networks linked by gateways. The term "internet" means any combination of networks in general: In fact, to avoid confusion with "The Internet", as we call it, corporations denote their internal internets "intranets." Gateways are devices that connect networks in an internet, as was just implied. Routers are devices that decide which way data is going to travel over a network to get from point A to point B. Incidentally, a subnet is a network in an internet. Go figure.
<H1>The TCP/IP Suite</H1>
<P>"So where does TCP/IP come in," you wonder? To set the record straight, TCP (Transmission Control Protocol) and IP (Internet [general, not specific to the Internet] Protocol) are just two internet data transfer protocols. IP is the basis of all Internet communications. TCP is the underlying protocol that makes communications on the global Internet reliable. The TCP/IP suite, on the other hand, is a group which contains most of the essential internet-related protocols that you'll ever worry about. It is comprised of protocols in two basic layers. The first and foremost layer in the suite is the Network Layer, which contains the basic, underlying protocols that make Internet communications possible. The layer above this is the Application Layer, which contains high-level protocols (those with which the user must interact) designed to transmit commands specific to a certain task.
<P><B>What's a protocol and how do I use it?</B>
<P>Loosely stated, a protocol is an established format for data transactions over a network. Network-level protocols in the TCP/IP family, namely DP, TCP, ICMP, IP, ARP, and RARP (those are the ones which you will ever even remotely have a chance of using as a game developer, in that order) are almost always implemented by the operating system, which is a blessing beyond all other blessings.
<P>This means that when we're concerned with developing applications that use the TCP/IP protocol suite for Internet communications, we usually interface to its Network level protocols by calling upon the operating system or operating system extension API functions. Attempting to implement the entire Network-level TCP/IP suite is overkill, especially since it has already been done for just about every platform (including DOS) that is currently in widespread use. If you ever did decide to implement it, the information to do so is freely available...but it's a lot of work, and might I add a lot of unnecessary work.
<P><B>How are protocols maintained by the Global Internet?</B>
<P>Protocols are only a small part of a large process of Internet standardization. Standardization and modernization is an entirely open, ongoing effort, carried out by way of memos called Requests for Comments (RFCs). When a proposed standard or effort that requires the attention of the entire professional Internet community is to be addressed, usually the ideas involved are published in the form of an RFC. Note that RFCs are a form of technical Internet intercommunication, and are usually not intended as documentation; generally, they either express respected and developed research that may or may not improve and update the network, or refine older standards. They are numbered in order of publication, starting with RFC 1, which was, incidentally enough, put out back in 1969. At the time of this writing, they approach 2500 in number [that should keep this "current" for long enough...]
<P>In order to facilitate better understanding of the contents of Requests for Comments, they are classified into various groups. Informational RFCs are, obviously, informational, and Exprerimental RFCs are experimental (surprise surprise). <P>Standards Track RFCs are RFCs in various stages of standardization, ranging from Proposed Standard, to Draft Standard, to Internet Standard. In order to become a standard, an RFC must move along the full run of the standards "track". The "track" is a set of rigorous phases of scrutiny, testing, review, and refinement that any standard on the Internet must go through before it can really be called "standard." The Internet Standards Track Reference is a document containing the state of standardization of various standards.
<P>Historic and Obsoleted RFCs are somewhat different, at least I like to think so; the historic RFC is one maintained for its historical interest, as if it ever had a practical one. Among these are included memos from the 60's or 70's discussing network meetings. Obsoleted RFCs contain information which has been outdated by newer developments. Usually, where an obsolete RFC is listed, the RFC which has obsoleted it is listed alongside it.
<P>Incidentally, all RFCs of which I am aware are distributed on an unlimited basis, which means that you can pretty much find them anywhere. They're available freely. However, since there are absolutely no distribution restrictions whatsoever, you also have the right to rip people off for them (but only an ignoramus would buy what he can get in the same condition for free!) A good RFC archive is at <A HREF="javascript:if(confirm('http://info.internet.isi.edu/1s/in-notes/rfc/files \n\n这个文件不能通过 Teleport Pro 取回, 因为 它被访问于一个域或在它的起始地址边界外部的路径上. \n\n你想从服务器打开它吗?'))window.location='http://info.internet.isi.edu/1s/in-notes/rfc/files'" tppabs="http://info.internet.isi.edu/1s/in-notes/rfc/files">http://info.internet.isi.edu/1s/in-notes/rfc/files</A>. You might want to refer to the RFCs for in-depth discussions on unusual standards. The information is all there.
<P>By the way, I don't believe I mentioned it...RFC 2324 is my present favorite.
<P><B>The TCP Protocol</B>
<P>TCP is crucial in reliable Internet communications. It does quite a bit. Foremost, it monitors what gets through to a remote host and what does not, and retransmits anything that doesn't. It also must perform other assorted tasks. Say that a packet is too large to fit into one IP packet: TCP will split it up into smaller packets. The TCP protocol uses the IP protocol to actually transmit data. Basically, the goal of TCP is to make sure that data gets from a place to another place in 100% intact condition. This "perfectness" is absolutely essential for the Internet to be worth-while at all: If one op-code in a binary is misplaced, the whole thing falls appart. One misplaced digit in a military data file could spell disaster. <P>Multiple conversations can be going on between two machines at the same time between more than one process on these machines. The ability to handle this scenario is called multiplexing, and TCP provides a set of "ports", uniquely identified via "port numbers" on a given host, through which various data are sent and received, in order to pull it off. There are assigned TCP port numbers for various application protocols. Beyond this, a user process may independently select ports for a conversation. This port information, together with the information that the IP protocol uses to identify an individual machine on the Internet, forms what is called a TCP socket, or alternatively, just a socket. All sockets are completely unique on the Internet, that is, a socket is on one and only one host and one and only one port on that host.
<P>To use TCP, you must connect a socket on the local machine to a socket on the remote machine. This occurs in three steps: First, TCP sends over a connect message from the local socket. The remote machine acknowledges, the remote socket sending a response to the local socket. Then the socket on the local host again acknowledges. A TCP connection is then said to have been opened. This process of negotiating a connection is called handshaking. Specifically, the handshaking method that TCP uses is called a three-way handshake. Once a connection has been formed, TCP can transmit data. TCP communication is bidirectional, that is, both parties in a connection can send and receive data. A single TCP socket can participate in more than one connection at a time, and can have more than one remote socket connected to it. Because of the significance of establishing connections in TCP, it is refered to as a connection-oriented protocol.
<P>TCP takes basic data that needs to be transfered and wraps a header around it. The header is complicated, but then again, so is TCP. Here's generally what it looks like:
<CENTER><P><B>TCP Header</B>
<TABLE WIDTH="50%" CELLSPACING=0 CELLPADDING=0 BORDER=3>
<TR><TD><B>Item</B></TD><TD><B>Size (bits)</B></TD></TR>
<TR><TD>Source Port</TD><TD>16</TD></TR>
<TR><TD>Destination</TD><TD>16</TD></TR>
<TR><TD>Sequence #</TD><TD>32</TD></TR>
<TR><TD>Ack. #</TD><TD>32</TD></TR>
<TR><TD>Data Offset</TD><TD>4</TD></TR>
<TR><TD>[Reserved]</TD><TD>6</TD></TR>
<TR><TD>Control Bits</TD><TD>6</TD></TR>
<TR><TD>Window</TD><TD>16</TD></TR>
<TR><TD>Checksum</TD><TD>16</TD></TR>
<TR><TD>Urgent Pointer</TD><TD>16</TD></TR>
<TR><TD>Options</TD><TD>Not fixed (multiple of 8)</TD></TR>
<TR><TD>Padding</TD><TD>Optional, only used if packet doesn't end on 32-bit boundary</TD></TR>
</TABLE></CENTER>
<P>In general, you can expect to see TCP headers getting to about 22 octets (an octet is an 8-bit byte) on average. Despite the meager sound of it, this is a quite large and cumbersome header size. It is for this reason, the huge header, coupled with the reason that TCP is just fundamentally "the wrong thing" for a game, that TCP is rarely used in games. What I mean by "the wrong thing" is explained best by way of example...if you shoot someone in a deathmatch and a TCP packet is sent to indicate it, what's the point of retransmitting it ten times until it's in perfect order? The fellow you shot is already cold by the time it finally gets through.
<P><B>The UDP Protocol</B>
<P>The User Datagram Protocol is another common protocol in the TCP/IP suite. The protocol was designed to provide an ad-hoc direct transportation mechanism for information without oversized TCP headers and the complexity associated with them. However, what UDP gains in elegance, it loses in reliability. Unlike TCP, UDP does not implement "quality assurance" with regard to the data that it transmits, in any way, shape, or form. UDP packets may be duplicated, out of order, or not received at all. On the other hand, UDP does cut back on the mammoth TCP header overhead, which adds up over time, especially if your TCP packets are so large and ill-designed as to consistently be split up.
<P>The aspect of UDP that stems largely from its intended design as a generic, low-key data transport mechanism is that it is entirely connectionless. That is to say, one does not have to establish a connection to a remote host in order to transmit packets to it or receive packets from it under UDP. Packets are simply transmitted over the network. Although it may seem odd, this model is basically what allows UDP to remain as compact as it is.
<P>The User Datagram Protocol tacks the following header onto the top of the data:
<CENTER><P><B>UDP Header</B>
<TABLE WIDTH="50%" CELLSPACING=0 CELLPADDING=0 BORDER=3>
<TR><TD><B>Item</B></TD><TD><B>Size (bits)</B></TD></TR>
<TR><TD>Source Port</TD><TD>16</TD></TR>
<TR><TD>Destination</TD><TD>16</TD></TR>
<TR><TD>Length</TD><TD>16</TD></TR>
<TR><TD>Checksum</TD><TD>16</TD></TR>
</TABLE></CENTER>
<P>8 octets as opposed to 22+...it's quite a simplification indeed. Always bear in mind, however, that UDP is unreliable, and you never know how unreliable. Design carefully. <P>It should also be noted that in the context of UDP, port numbers have less significance on the Network level than do TCP port numbers. Rather, UDP port numbers are more significant towards an individual application. There are, however, established UDP protocol port numbers, as there are established TCP port numbers, for various application level protocols. Rule of thumb: Always, always check both the assigned port numbers and the commonly used port numbers before you attempt to use a port for personalized data transport, and even then only use a port towards the top of the accepted "user" port list. You will usually find links to assigned port information on the web alongside RFC listings.
<P><B>The IP Protocol</B>
<P>IP is relied upon by just about everything. It's the cornerstone of all Internet communications. IP also is rather conceptually simple. It has exactly one goal and one dream in life, and that's to get packets from a source address to a destination address. IP transmits data in the form of packets called datagrams. Datagrams are composed of a header, which is 20 octets large, and a data area. Although IP doesn't give a rip about what's inside the data area, usually the data area will be composed of a TCP or UDP header followed by raw data when IP sees it. Thus, the IP header is just plopped on top of any other headers that might be present over the data. This is how Internet communications works in general; layers of protocols on the local host wrap their headers around the data and it is transmitted, then various layers peal the headers away from the data as it is processed by the remote host, and eventually a specific application gets the data.
<CENTER><P><B>IP Header</B>
<TABLE WIDTH="50%" CELLSPACING=0 CELLPADDING=0 BORDER=3>
<TR><TD><B>Item</B></TD><TD><B>Size (bits)</B></TD></TR>
<TR><TD>Version Number</TD><TD>4</TD></TR>
<TR><TD>Header Length</TD><TD>4</TD></TR>
<TR><TD>Type of Service</TD><TD>8</TD></TR>
<TR><TD>Packet Length</TD><TD>16</TD></TR>
<TR><TD>Packet ID</TD><TD>16</TD></TR>
<TR><TD>Fragmentation</TD><TD>16</TD></TR>
<TR><TD>Time to Live</TD><TD>8</TD></TR>
<TR><TD>Protocol</TD><TD>8</TD></TR>
<TR><TD>Header Checksum</TD><TD>16</TD></TR>
<TR><TD>Source Address</TD><TD>32</TD></TR>
<TR><TD>Destination Address</TD><TD>32</TD></TR>
</TABLE></CENTER>
<P><B>IP Addresses</B>
<P>IP addresses are the standard means of identifying Internet hosts. An IP address is a 32-bit integer. By convention, in written form, each octet of an IP address is written in base-10, separated by a ., big endian. Consider that you are on a little-endian machine (the least significant octet of a word trails in memory). When an IP address, or any data for that matter, is received from a big-endian remote host, you must convert it to little-endian before it is significant to the machine. Big-endian notation is always used to represent IP addresses. For this reason, big-endian is said to be the network byte order. TCP/IP implementations will usually provide functions to convert from the network byte order to the local host's byte order, and should, if competent, process the information in the header correctly regardless of byte order.
<P>For instance, the IP address 127.0.0.1 is the "local loop-back" address by convention for the Linux TCP/IP implementations, which means that data sent to this address will be looped back to you. (Just an interesting tid-bit.)
<P>In order to facilitate networks of different sizes, IP addresses are divided into a network address and a host address. The network address identifies the network in an internet to which a datagram is being sent, and the host address identifies the specific host on that network to give the datagram to. The way in which these portions of the address are allocated determines the "class" of an IP address. IP addresses are organized into four distinct classes.
<CENTER><P><B>IP Address Classes</B>
<TABLE WIDTH="90%" CELLSPACING=0 CELLPADDING=0 BORDER=3>
<TR VALIGN="top">
<TD><B>Class</B></TD>
<TD><B>Number of Network Addresses</B></TD>
<TD><B>Number of Host Addresses</B></TD>
<TD><B>Generalization</B></TD>
</TR>
<TR VALIGN="top">
<TD>A</TD>
<TD>126</TD>
<TD>16,177,214</TD>
<TD>One of few mammoth networks</TD>
</TR>
<TR VALIGN="top">
<TD>B</TD>
<TD>16,383</TD>
<TD>65,534</TD>
<TD>One of many larger networks</TD>
</TR>
<TR VALIGN="top">
<TD>C</TD>
<TD>2,097,162</TD>
<TD>254</TD>
<TD>One of a lot of small networks</TD>
</TR>
<TR VALIGN="top">
<TD>Ext.</TD>
<TD>N/A</TD>
<TD>Indefinite</TD>
<TD>N/A</TD>
</TR>
</TABLE></CENTER>
<P>We never really need to worry about these classes, but if you're curious,
the class of an IP address can be physically determined in two ways: First
off, if there's a pink flamingo anywhere on its front lawn and it drives a
sport utility vehicle, then it is probably of a higher class. The other
common approach is to look at the range of its most significant octet. A
MSO from 0-127 indicates class A, from 128-191 class B, from 192 to 223
class C, and from 224-255 an extension address.
<P>The extended IP address class, described in RFC 1112, is used for
multicasting (sending a single packet to more than one host at a time), and
we will not concern ourselves with it.
<P>One would like to think that this is it. However, on a lower level, there's
still the concern of how IP gets a packet to a given IP address. This
process is called routing, and can become moderately complicated.
Fortunately enough, for our purposes, it's simple, because we don't have to
implement it.
<P><B>The Domain Name System</B>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -