JSP Web Hosting Blog

Basic TCP/IP TCP/IP is the general label applies to a whole bunch of different protocols that hold the Internet together. Each protocol has its own rules and methods. We’re going to discuss four protocols here: Internet Protocol, Internet Control Message Protocol, Transmission Control Protocol, and User Datagram Protocol. You can get a partial list of protocols in /etc/protocols. IP IP provides two basic services: the formation of packets that can be transmitted over TCP/IP networks and the addressing scheme. We’ve already discussed both of those in as much detail as we’re going to, so I’ll leave it here. IP is protocol number 0. ICMP Internet Control Message Protocol is a standard for transmitting routing and availability messages across the Internet. Tools such as ping(8) and traceroute(8) use ICMP to gather their results. ICMP packets are vital to normal network behavior, but can be used to gather information about your network. We’ll examine how this can be avoided without breaking basic functions in Chapter 17. UDP The User Datagram Protocol is arguably the most bare-bones data transfer protocol possible that can run over IP. It has no error handling, no content verification, and no defense whatsoever against data loss. Despite these drawbacks UDP can be a good choice for particular sorts of data transfer, and many vital Internet services use it. When a host transmits data via UDP, it doesn’t know if the data ever reaches its destination. Programs that receive UDP data simply listen to the network and receives what comes that way. When that program receives data via UDP, it has no way to verify the source of that data. While UDP packets include a source address, this is very easily faked. This is why UDP is called connectionless. An application using UDP most often has its own error-correction requirements that don’t jibe with those provided by protocols such as TCP. For example, client DNS queries need to time out within just a few seconds. TCP times connections out after several minutes. Because a system wants to reject a failed DNS request well before that, UDP is used. TCP Transmission Control Protocol includes such nifty things as error correction and packet recovery. The receiver must acknowledge every packet sent, or it will be retransmitted. Applications that use TCP can expect reliable data transmission (unless, of course, something goes wrong at the physical layer). Unlike UDP, TCP is a connected protocol. For data to be transmitted, the two hosts must set up a channel for data to flow across. One host requests a connection, the other host responds to the request, and then the first host starts transmitting. This setup process is known as the three-way handshake. The exact specifics are not important right now, but you should know that this process happens. It will become quite important when we start talking about packet filtering in Chapter 17. Similarly, once a data transmission is complete the system must do a certain amount of work to tear down the connection. How Protocols Fit Together You can compare IP, ICMP, TCP, and UDP to sitting with your family at a holiday dinner. IP gives every person at the table a unique chair. ICMP lets you see the other people at the table, and understanding that to hand the peas to your doddering Uncle Chris you must pass it by Cousin Phil. TCP is where you hand someone a dish and the other person must say “thank you” before you will let go. Finally, UDP is like tossing a muffin at Aunt Betty: She might catch it, it might bounce off her forehead, or it could be snatched out of midair by the dog. Network Ports Have you ever noticed that computers have too many ports? Well, we’re going to add TCP and UDP ports into the mix. Protocol ports permit one server to provide many different network services over a single protocol, multiplexing connections between machines. When a TCP or UDP packet arrives at a system, it requests delivery to a certain port. Server programs Page 168

Hint: If you are looking for very good and affordable webspace to host and run your tomcat hosting application check Virtualwebstudio tomcat web hosting provider

decimal numbers are easiest to work with. [3] If your company is hooking up to the Internet, your ISP will issue you a block of IP addresses. Frequently this is a small block, say, 16 or 32 IP addresses. If your system is colocated on a server farm, you might only get a few IP addresses. It all depends upon your needs. The size of your IP block determines your netmask or, the size of your netmask determines how many IP addresses you have. If you’ve done networking for any length of time, you’ve seen the netmask 255.255.255.0. You might even know that the wrong netmask will keep your system from working. In today’s world, that simple netmask is becoming less and less common. To understand why this is, you need to understand something about the history of IP addressing. Many years ago, IP addresses were issued in blocks of three sizes: class A, class B, and class C. (There were also a few chunks of class D and class E space, but those really aren’t relevant to the discussion.) This terminology has been obsolete for quite some time, but we’ll use it as a starting point. Class A was very simple: The first of the four numbers in an IP address were fixed. The InterNIC might issue you a class A like “10.0.0.0.” You could assign any of the last three numbers in any manner you liked, but all your IP addresses began with 10. For example, you could delegate 10.1.0.0 through 10.1.1.255 to your data center, 10.1.2.0 through 10.1.7.255 to your Detroit office, and so on. Only very large companies, such as Ford and Xerox, as well as influential academic computing institutions such as MIT, received class A blocks. In a class B block, the first two of the four numbers in the IP address were fixed. Your class B block would look something like 192.168.0.0. Every IP address you used internally began with the first two numbers 192.168, but you could assign the last two numbers as you wanted. Many midsized companies got class B blocks. Similarly, a class C block had the first three numbers fixed. This was the standard for small companies. The ISP would issue a block like 209.69.178.0 and let you assign the last number as you wanted. This scheme wasted a lot of IP numbers. Many small companies don’t need 256 IP addresses. Many medium-sized companies need more than 256, but fewer than the 65,000 in a class B block. And almost nobody needs the full 16 million addresses in a class A block. Still, those were the choices. Before the Internet boomed, they were good enough. Remember, back in the 1980s the thought that private individuals would hook up to the Net from home, for entertainment, was laughable. Today, IP addresses are issued by prefix length, commonly called a slash. You will see IP blocks such as 192.168.1.128/25. While this looks confusing, it’s merely a way of using classes with much greater granularity. You know that each number in an IP address is 8 bits long. By using a class, what you’re saying is that a certain number of bits are “fixed” you cannot change them on your network. A class A address has 8 fixed bits, a class B has 16, and a class C has 24. This isn’t a class in binary math, so I won’t make you draw it out and do the conversion. But think about an IP address as a string of binary numbers. On your network you can change the bits on the far right, but not the ones on the far left. There’s no reason that the boundary between the two must be on one of those convenient 8-bit lines that separate the decimal versions of the numbers. A prefix length is simply the number of fixed bits you are stuck with. A /25 means that you have 25 fixed bits, or one more fixed bit than what used to be called a class C. You can play with 7 bits. In the following sample, your fixed bits are all ones, and the bits you can change are zeros. 11111111.11111111.11111111.10000000 It’s very simple if you think in binary. You won’t have to work with this every day, but if you don’t understand the underlying binary concepts, the decimal conversion looks like total gibberish. With practice, you’ll learn to recognize some bits of decimal gibberish as legitimate binary conversions. So, that’s the theory. What does this mean in practice? Page 165

Hint: If you are looking for very good and affordable webspace to host and run your tomcat hosting application check Virtualwebstudio tomcat web hosting provider

First of all, blocks of IP addresses are issued in multiples of 2. If you have 4 bits to play with, you have 16 IP addresses (2*2*2*2=16). If you have 8 bits to play with, you have (2^8) 256 IP addresses. If someone says you have 13 IP addresses, you’re either sharing an Ethernet with other people or they’re wrong. A netmask is simply another way of specifying how many bits are fixed. In the computing world, an 8-bit number runs from 0 to 255. If you have 24 fixed bits, also known as a /24, and formerly known as a class C, your netmask is 24 ones followed by eight zeros: 11111111.11111111.11111111.00000000, or 255.255.255.0. If you’ve been around a few networks, that should look familiar. If you have a /25, however, you have 25 fixed bits. This comes to 11111111.11111111.11111111.10000000, or 255.255.255.128. It’s not uncommon to see a host’s IP address with its netmask attached, e.g. 192.168.3.4/26. This gives you everything you need to know to get the host on the network. (Finding the default gateway would be another issue, mind you!) Computing Netmasks in Decimal You probably don’t want to repeatedly convert from decimal to binary and back. Here’s a trick to calculate your netmask while staying in decimal land. First, learn how many actual IP addresses you have. This will be a multiple of 2. You’ll almost certainly be issued a network smaller than a /24. Subtract the number of IP addresses you have from 256. This is the last number of your netmask. For example, if you have a /26, or 64 IP addresses, the last part of your netmask is (256-64=)192. Your netmask would be 255.255.255.192. You still need to use a bit of logic to avoid binary conversions. Figuring out legitimate addresses on your network can be a bit of a pain. If your IP address is 192.168.1.100/26, you’ll need to know that a /26 is 26 fixed bits, or 64 IP addresses. Look at the last number of your IP address, 100. It certainly isn’t between 0 and 63, but it is between 64 and 127. The other hosts on your IP block have IP addresses ranging from 192.168.1.64 to 192.168.1.127. At this point, I should mention that netmasks are frequently shown in hex numbers. You might feel like throwing up your hands and giving up the whole thing. To simplify your life, I’m including a table of netmasks, IP information, and general goodness for /24 and smaller networks. Table 8-1: Netmasks and IP address conversions Prefix Binary Mask Decimal Mask Hex Mask Available IPs /24 00000000 0 0×00 256 /25 10000000 128 0×80 128 /26 11000000 192 0xc0 64 /27 11100000 224 0xe0 32 /28 11110000 240 0xf0 16 /29 11111000 248 0xf8 8 /30 11111100 252 0xfc 4 /31 11111110 254 0xfe 2 /32 11111111 255 0xff 1 Unusable IP Addresses Page 166

Hint: If you are looking for very good and affordable webspace to host and run your tomcat hosting application check Virtualwebstudio tomcat web hosting provider

and there is no security without understanding, so we’re going to briefly discuss bits here. You probably already know that a computer treats all data as zeros and ones, and that a single one or zero is a bit. When a protocol specifies a number of bits, it’s talking about the number as soon by the computer. A 32-bit number has 32 digits, all of which are either one or zero. You were probably introduced to binary math, or base 2, back in elementary school and remembered it just long enough to pass the test. Binary math is simply a different way to work with the same numbers we see every day. In decimal math (or base 10), the math we typically use every day to balance our checkbook or figure out how much over the speed limit we’re driving, digits run from 0 to 9. When you want to go above the highest digit you have, you add a digit on the left and set your current digit to 0. (This is the whole “carry the one” thing you learned many years ago, and now probably do without conscious thought.) Binary math is exactly the same, except that digits run from 0 to 1. When you want to go above the highest digit you have, you add a digit on the left and set your current digit to 0. It’s the same thing, just with fewer digits. Here are the first few decimal numbers converted into binary as an example. Decimal Binary 0 0 1 1 2 10 3 11 4 100 5 101 6 110 7 111 8 1000 When you have a 32-bit number, such as an IP address, you have a string of 32 ones and zeros. Ethernet MAC addresses are 48-bit numbers. Got that? Good. Just to make things difficult, UNIX also uses hexadecimal numbers in some cases (such as MAC addresses and netmasks). Hexadecimal numbers are 4 bits long; each digit goes up to 16. This is accomplished by using the numbers 0 through 9, plus the letters A through F. When you reach the last digit, you reset the current digit to zero and add a digit to the left of the number. For example, to count to sixteen in hexadecimal you go “1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, 10.” Numbers in hexadecimal are usually marked with a leading “0x.” The number 0×11 is a hexadecimal number equal to the decimal number 17, while the number 11 is plain old decimal 11. (If a hex number is not marked by a leading 0x, it’s usually in a place where the output is always in hex numbers.) When you’re working with hexadecimal, decimal, and binary numbers, the simplest thing to do is to break out a scientific calculator. All modern medium-end or better calculators have functions to convert between the three systems. Even the Microsoft Windows calculator has that function. If you want to stick with OpenBSD, you can install /usr/ports/math/hexcalc (see Chapter 13). IP Addresses and Netmasks An IP address is a unique 32-bit number assigned to a particular network node. Some IP addresses are more or less permanent, such as those assigned to servers. Others change as required by the network, such as those used by dial-up clients. Individual machines on a shared network get adjoining IP addresses; we’ll explore what this means a little later. Rather than expressing that 32-bit number as a single number, IP addresses are broken up into four 8-bit numbers. (We’ll see why in a little bit.) These numbers are expressed as decimal numbers. While 192.168.1.1 is the same as the four binary numbers 11000000.10101000.00000001.00000001, or 11000000101010000000000100000001, or even the hexadecimal c0.a8.1.1 or 0×30052000401, the four Page 164
Note: If you are looking for top 10 and very good webhost to host and run your jsp application check Actions jsp hosting services

Networking Basics This section introduces the basics of networking in OpenBSD and some tools you need to be able to work well with it. Some parts are common to all sorts of TCP/ IP networks, such as IP addresses. Others are specific to BSD-based operating systems, such as mbufs. The power offered by OpenBSD requires more understanding than that needed to run a point-and-click operating system. Mbufs OpenBSD optimizes networking by using mbufs. An mbuf is a discrete chunk of kernel memory set aside for networking. A packet starts off life as a mbuf. Rather than copying the contents of a packet to the next network layer, each layer passes around a pointer to the mbuf. Copying the data consumes far more time and resources than simply handing off responsibility for the data while leaving the data itself in the same spot. Mbufs are carefully designed to not require dramatic changes. When the logical protocol creates an mbuf, it leaves space at the front and back for physical protocol headers, which further minimizes the amount of copying required. A packet becomes a frame within the same mbuf. Those of you who are C programmers should recognize a pointer here. The pointer to the mbuf is handed around, while the mbuf itself remains constant. The rest of us just need to have a basic idea of what an mbuf is. You’ll keep tripping across mentions of mbufs throughout documentation on the OpenBSD network stack, so it’s important to at least have a vague awareness of them. How Many Mbufs? Each kernel allocates a certain number of mbufs. When you run out of mbufs, you can’t push more data. This raises the obvious questions: How many mbufs do you have, and how can you get more? The netstat(1) command is a general interface into the network stack. It has many functions that are wildly different. While this is definitely a deviation from the UNIX philosophy of “small tools that each do one thing well,” netstat has been this way for so long that nobody’s really inclined to change it. The “-m” flag to netstat gives some basic mbuf information. # netstat -m 1 18 mbufs in use: 2 1 mbuf allocated to packet headers 17 mbufs allocated to socket names and addresses 0/12 mapped pages in use 36 Kbytes allocated to network 3 (12% in use) 0 requests for memory denied 0 requests for memory delayed 0 calls to protocol drain routines # Here, we see 1 how many mbufs have been used and 2 what part of the network they’re being used for. We also can see 3 how much of the kernel memory reserved for network operations is in use. This particular system has lots of kernel memory left and is using very few mbufs. The number of mbufs a system has is controlled by the NMBCLUSTERS kernel option. Changing this requires patching your kernel. Take a look at Chapter 11 for some discussion of what this implies. Generally speaking, your system will complain if it starts running out of mbufs; you will see “mclpool limit reached” messages on the console and in /var/log/messages. Bits As a systems administrator, you’re going to start seeing terms like 32-bit and 48-bit more and more frequently. Too many sysadmins just nod and smile when they see these terms, but don’t really understand what they mean. If you’re running OpenBSD, that means you have an interest in security, Page 163
Note: If you are looking for top 10 and very good webhost to host and run your jsp application check Actions jsp hosting services

This seems like an awful lot of work, but it’s an excellent example of why layering is important. Each layer knows only what it absolutely must about the layers above and below it, making it possible to swap out the innards of layers if desired. When a new physical protocol is created, the other layers don’t have to care; the logical protocol just hands the request off to the physical protocol layer and lets that layer do its thing. When you have a new type of network card, all you need to do is write a driver that interfaces with the physical protocol; the application and logical protocol layers don’t care. [2]Unless, of course, some of it breaks, in which case your managers will want to know exactly what sort of equipment it is, how long it will take to repair, and why you need it anyway. Page 162

Note: If you are looking for good and affordable webspace to host and run your servlet application check Virtualwebstudio servlet hosting services

The Life and Times of a Network Request Now that you understand something about the function of each layer, let’s look at how this works in the real world. Some of this touches on stuff that we’ll cover later in this chapter, but if you’re reading this book you’re probably conversant enough with networks that you’ll be able to follow it. If you have trouble, you may want to read this section once again after finishing the chapter. Suppose a user on a computer connected to the Internet via your company’s Ethernet wants to look at the Yahoo web page. The user interfaces with the application and types in the URL. The web browser needs to know how to make requests of the next layer down, so it translates the host name into an IP address and sends a request for a connection to TCP port 80 on that IP address down to the logical protocol layer. The logical protocol layer examines the request it has received from the application. Because the application has requested a TCP/IP connection, the logical protocol allocates the appropriate system resources for that sort of connection. The request is broken up into chunks, or packets, to be sent over Internet Protocol. From here on, the logical protocol doesn’t care about the application’s actual request; instead, it wants to deliver these packets to the address required. The Internet Protocol subsystem checks its internal tables to see how to reach the requested IP address from this computer. It then bundles up the packets, adds on the IP routing information, and hands the packets to the physical protocol layer. The physical protocol layer examines the request from the logical protocol layer. The logical protocol doesn’t know anything about the packets it is given; it doesn’t know that this is a web request or its final destination. All it knows about is getting each packet to its destination. The physical protocol just knows that it needs to add its own information to the packet. This packet-plus-physical-protocol chunk of data is called a frame. Finally, it hands the frame off to the physical layer for broadcast on the local Ethernet. The physical layer simply transmits a bunch of zeros and ones over the local network. It has no idea what sort of protocol is being spoken, or how these numbers may be echoed through a switch, hub, or repeater, but one of the hosts on this network is presumably the router out of the network. The physical layer of your router accepts these zeros and ones and hands them up to the physical protocol. The physical protocol will strip off the Ethernet information and hand the resulting packet up to the logical protocol handler within the router. The router’s logical protocol layer examines the packet, specifically checking the destination address. Once it knows where the packet is supposed to go, it can consult its internal routing tables and decide how to get the packet to that destination. It then hands the packet down to a physical protocol layer. This might be another Ethernet interface, or (more likely) a PPP interface out over a T1. Your wire can go through various physical changes as your data travels. For example, your T1 line can be aggregated into a DS3 over fiber, which could then be transformed into an OC192 cross-country link. Thanks to the wonders of layering and abstraction, you don’t need to know about any of these. [2] When your request finally reaches its destination, the computer at the other end of the transaction, it starts a return trip all the way back up the protocol stack. The physical layer gives each frame to the physical protocol, which does some basic sanity checking on the frame to be sure it hasn’t been corrupted in transit. Once the physical protocol layer is satisfied that the frame is correct, it removes the physical protocol encapsulation and hands a naked packet up to the logical protocol. The logical protocol, in turn, performs its own sanity checking. Remember how the logical protocol broke up the request into packets for easy handling? Now it assembles the packets into a stream of data. It then hands this stream of data to the application in this case, a web server. The application can process the request and return an answer. This answer descends the protocol stack again and travels across the network, bouncing up and down various protocol stacks along the way as necessary. And if this doesn’t all happen very, very quickly, your user will call the help desk and complain. Page 161

Note: If you are looking for good and affordable webspace to host and run your servlet application check Virtualwebstudio servlet hosting services

Network Layers Every piece of the network is divided into layers. Each layer handles a specific part of the networking process and interacts only with the layers above and below it to provide a solid connection. New users often have trouble understanding this and laugh when it’s said that layers “simplify” the networking process. We’ll go over it in some detail, but the important thing to remember right now is that each layer only communicates with the layer directly above it and the layer directly beneath it. The classic OSI network layer diagram has seven pieces, is exhaustively complete, and covers any situation in any network protocol. The Internet isn’t “every situation” however, and this isn’t a book about networking. We’re limiting our discussion to the Internet and other networks that use the same protocols, so we can simplify this somewhat and divide the network into four layers: the application, the logical protocol, the physical protocol, and the physical layer. The Physical Layer At the very bottom we have the physical layer, which includes the network card and the wire, fiber, or radio waves running out of it. This layer includes the physical box that is a switch, hub, or base station, wires running from that device to the router, and the fiber that runs from your office to the telephone company. The telephone company switch is part of the physical layer, as are the transcontinental fibers. If someone can smash, drop, or cut it and inconvenience you, it’s part of the physical layer. From this point on we’re going to refer to the physical layer as a “wire,” although it can be just about any sort of hardware. A piece of wire, or some other physical media for signals to travel over it’s really that simple. If your wire is intact and meets the requirements of the physical protocol, you’re in business. If not, you’re hosed. Without a physical layer, the rest of the network will not function, period, end. One of the functions of Internet routers is to connect one sort of physical layer to another. The physical layer has no decision-making abilities and no intelligence; everything it does is dictated by the physical protocol. The Physical Protocol Layer The physical protocol layer is where things get interesting. The physical protocol talks over the wire. It encodes transmissions in the actual ones and zeros that are sent over the physical layer in the appropriate method for that sort of physical layer. For example, Ethernet uses Media Access Control (MAC) addresses and the Address Resolution Protocol (ARP); dial-up and wide area networks use the Point-to-Point Protocol (PPP). The physical protocol has to know how to speak to the physical layer. While Ethernet and PPP are the most popular physical protocols, you will find many other protocols such as Asynchronous Transfer Mode (ATM), High Level Data Link Control (HDLC), and Internetwork Packet Exchange (IPX), as well as combinations such as the PPP over Ethernet used by some home-broadband vendors. While OpenBSD supports many different physical protocols, it doesn’t support them all. If you have some unusual networking requirements, you will want to investigate whether OpenBSD can support them. Some physical protocols have been implemented over many different physical layers; for example, Ethernet has been transmitted over twoax [1], coax, cat3, cat5, cat7, optical fiber, and radio waves. With minor changes in the device drivers, the physical protocol can address any sort of physical layer. This is one of the ways in which layers simplify the network. We will discuss Ethernet and PPP in some detail. Once you understand those, you should be able to figure out how to use other protocols without too much difficulty. The physical protocol passes information to and from the physical layer to and from the logical protocol layer. The Logical Protocol Layer A computer program intended to run over any sort of network, over any sort of physical layer and physical protocol, cannot worry about the inner working of the physical protocol or physical layer. The logical protocol provides a consistent interface to programs that need to access the network, no matter which sort of physical layer it is running over. The most popular logical protocols are Internet Protocol Page 159
Note: If you are looking for high quality webhost to host and run your jsp application check Vision jsp hosting services

(IP) and Transmission Control Protocol (TCP). These protocols provide things such as IP addresses and port operations. When a packet is transmitted, it includes a flag that identifies which protocol it uses. Logical protocols can work side by side and can even depend upon one another. There are many logical protocols. See the file /etc/protocols for a mostly complete list. The ones we’re most concerned with are IP and TCP (already mentioned), Internet Control Message Protocol (ICMP), and User Datagram Protocol (UDP). The logical protocol talks to the physical protocol layer and to applications. Applications You can call applications another layer of the network. This is anything that the end user sees or any server program. Web browsers are applications, as are web servers, as are shell prompts and email clients, or compilers, or anything else. Applications only have to worry about the logical protocol and the application user. [1]”Twoax” required two thick pieces of cable for each network connection. I saw this on an IBM System 38 in the fall of 1999, on a system that didn’t speak TCP/IP. The moral of the story is: Be careful with what you implement today, because you may have to live with it for a very long time. Page 160
Note: If you are looking for high quality webhost to host and run your jsp application check Vision jsp hosting services

Chapter 8: Networking Overview TCP/IP: Learn how it fits together, You cannot escape. BSD is famous for its network performance. In fact, the TCP/IP network protocol itself was first developed in the days when BSD lived in Berkeley, and BSD was the first major deployment of TCP/IP. Many other operating systems have chosen to use the BSD network stack because of its high performance and liberal licensing. While other protocols were considered more exciting during the 1980s, the wide availability of the BSD stack made it the de facto standard. Many systems administrators today have a vague familiarity with some of the basics of networking, but don’t really understand how it all hangs together. Good sysadmins come from all walks of life, but they all have one thing in common: They understand the network. Knowing what an IP address really is, how a netmask really works, and what a port number means is part of what transforms a novice into a professional. We’ll cover some of these issues here. Note TCP/IP is a very dense topic, with many details, “gotchas,” and caveats. While this section gives a good overview, we cannot possibly cover everything. If you want to know more about TCP/IP, pick up one of the big thick books on the subject. My favorite is Stevens’ s TCP/IP Illustrated, volumes 1 through 3. Page 158
Note: If you are looking for good and quality webspace to host and run your java application check Actions java hosting services