{"id":96,"date":"2018-06-14T19:04:54","date_gmt":"2018-06-14T19:04:54","guid":{"rendered":"https:\/\/pressbooks.ccconline.org\/bus3060\/chapter\/ch12-3\/"},"modified":"2026-02-03T15:37:15","modified_gmt":"2026-02-03T15:37:15","slug":"ch12-3","status":"publish","type":"chapter","link":"https:\/\/pressbooks.ccconline.org\/bus3060\/chapter\/ch12-3\/","title":{"raw":"12.3 Getting Where You\u2019re Going","rendered":"12.3 Getting Where You\u2019re Going"},"content":{"raw":"
\r\n
\r\n
\r\n
\r\n

Learning Objectives<\/span><\/p>\r\n\r\n<\/header>\r\n

\r\n

After studying this section you should be able to do the following:<\/p>\r\n\r\n

    \r\n \t
  1. Understand the layers that make up the Internet\u2014application protocol, transmission control protocol, and Internet protocol\u2014and describe why each is important.<\/li>\r\n \t
  2. Discuss the benefits of Internet architecture in general and TCP\/IP in particular.<\/li>\r\n \t
  3. Name applications that should use TCP and others that might use UDP.<\/li>\r\n \t
  4. Understand what a router does and the role these devices play in networking.<\/li>\r\n \t
  5. Conduct a traceroute and discuss the output, demonstrating how Internet interconnections work in getting messages from point to point.<\/li>\r\n \t
  6. Understand why mastery of Internet infrastructure is critical to modern finance and be able to discuss the risks in automated trading systems.<\/li>\r\n \t
  7. Describe VoIP, and contrast circuit versus packet switching, along with organizational benefits and limitations of each.<\/li>\r\n<\/ol>\r\n<\/div>\r\n<\/div>\r\n \r\n\r\n<\/div>\r\n
    \r\n

    TCP\/IP: The Internet\u2019s Secret Sauce<\/h2>\r\n

    OK, we know how to read a Web address, we know that every device connected to the Net needs an IP address, and we know that the DNS can look at a Web address and find the IP address of the machine that you want to communicate with. But how does a Web page, an e-mail, or an iTunes download actually get from a remote computer to your desktop?<\/p>\r\n

    For our next part of the Internet journey, we\u2019ll learn about two additional protocols: TCP and IP. These protocols are often written as TCP\/IP and pronounced by reading all five letters in a row, \u201cT-C-P-I-P\u201d (sometimes they\u2019re also referred to as the Internet protocol suite<\/em>). TCP and IP are built into any device that a user would use to connect to the Internet\u2014from handhelds to desktops to supercomputers\u2014and together TCP\/IP make Internet working happen.<\/p>\r\n\r\n

    \r\n

    Figure 12.4<\/span> TCP\/IP in Action<\/p>\r\n

    \r\n\"In\r\n<\/a><\/p>\r\n

    In this example, a server on the left sends a Web page to the user on the right. The application (the Web server) passes the contents of the page to TCP (which is built into the server\u2019s operating system). TCP slices the Web page into packets. Then IP takes over, forwarding packets from router to router across the Internet until it arrives at the user\u2019s PC. Packets sometimes take different routes, and occasionally arrive out of order. TCP running on the receiving system on the right checks that all packets have arrived, requests that damaged or lost packets be resent, puts them in the right order, and sends a perfect, exact copy of the Web page to your browser.<\/p>\r\n\r\n<\/div>\r\n

    TCP and IP operate below http and the other application transfer protocols mentioned earlier. TCP (transmission control protocol)<\/a><\/span> works its magic at the start and endpoint of the trip\u2014on both your computer and on the destination computer you\u2019re communicating with. Let\u2019s say a Web server wants to send you a large Web page. The Web server application hands the Web page it wants to send to its own version of TCP. TCP then slices up the Web page into smaller chunks of data called packets (or datagrams)<\/a><\/span>. The packets are like little envelopes containing part of the entire transmission\u2014they\u2019re labeled with a destination address (where it\u2019s going) and a source address (where it came from). Now we\u2019ll leave TCP for a second, because TCP on the Web server then hands those packets off to the second half of our dynamic duo, IP.<\/p>\r\n

    It\u2019s the job of IP (Internet protocol)<\/a><\/span> to route the packets to their final destination, and those packets might have to travel over several networks to get to where they\u2019re going. The relay work is done via special computers called routers<\/a><\/span>, and these routers speak to each other and to other computers using IP (since routers are connected to the Internet, they have IP addresses, too. Some are even named). Every computer on the Internet is connected to a router, and all routers are connected to at least one (and usually more than one) other router, linking up the networks that make up the Internet.<\/p>\r\n

    Routers don\u2019t have perfect, end-to-end information on all points in the Internet, but they do talk to each other all the time, so a router has a pretty good idea of where to send a packet to get it closer to where it needs to end up. This chatter between the routers also keeps the Internet decentralized and fault-tolerant. Even if one path out of a router goes down (a networking cable gets cut, a router breaks, the power to a router goes out), as long as there\u2019s another connection out of that router, then your packet will get forwarded. Networks fail, so good, fault-tolerant network design involves having alternate paths into and out of a network.<\/p>\r\n

    Once packets are received by the destination computer (your computer in our example), that machine\u2019s version of TCP kicks in. TCP checks that it has all the packets, makes sure that no packets were damaged or corrupted, requests replacement packets (if needed), and then puts the packets in the correct order, passing a perfect copy of your transmission to the program you\u2019re communicating with (an e-mail server, Web server, etc.).<\/p>\r\n

    This progression\u2014application at the source to TCP at the source (slice up the data being sent), to IP (for forwarding among routers), to TCP at the destination (put the transmission back together and make sure it\u2019s perfect), to application at the destination\u2014takes place in both directions, starting at the server for messages coming to you, and starting on your computer when you\u2019re sending messages to another computer.<\/p>\r\n\r\n

    \r\n
    \r\n

    UDP: TCP\u2019s Faster, Less Reliable Sibling<\/h4>\r\n

    TCP is a perfectionist and that\u2019s what you want for Web transmissions, e-mail, and application downloads. But sometimes we\u2019re willing to sacrifice perfection for speed. You\u2019d make this sacrifice for streaming media applications like Windows Media Player, Real Player, Internet voice chat, and video conferencing. Having to wait to make sure each packet is perfectly sent would otherwise lead to awkward pauses that interrupt real-time listening. It\u2019d be better to just grab the packets as they come and play them, even if they have minor errors. Packets are small enough that if one packet doesn\u2019t arrive, you can ignore it and move on to the next without too much quality disruption. A protocol called UDP (user datagram protocol)<\/a><\/span> does exactly this, working as a TCP stand-in when you\u2019ve got the need for speed, and are willing to sacrifice quality. If you\u2019ve ever watched a Web video or had a Web-based phone call and the quality got sketchy, it\u2019s probably because there were packet problems, but UDP kept on chugging, making the \u201cget it fast\u201d instead of \u201cget it perfect\u201d trade-off.<\/p>\r\n\r\n<\/div>\r\n \r\n\r\n<\/div>\r\n

    \r\n
    \r\n

    VoIP: When Phone Calls Are Just Another Internet Application<\/h4>\r\n

    The increasing speed and reliability of the Internet means that applications such as Internet phone calls (referred to as VoIP<\/em>, or voice over Internet protocol<\/a><\/span>) are becoming more reliable. That doesn\u2019t just mean that Skype becomes a more viable alternative for consumer landline and mobile phone calls; it\u2019s also good news for many businesses, governments, and nonprofits.<\/p>\r\n

    Many large organizations maintain two networks\u2014one for data and another for POTS<\/em> (plain old telephone service). Maintaining two networks is expensive, and while conventional phone calls are usually of a higher quality than their Internet counterparts, POTS equipment is also inefficient. Old phone systems use a technology called circuit switching<\/em>. A \u201ccircuit\u201d is a dedicated connection between two entities. When you have a POTS phone call, a circuit is open, dedicating a specific amount of capacity between you and the party on the other end. You\u2019re using that \u201ccircuit\u201d regardless of whether you\u2019re talking. Pause between words or put someone on hold, and the circuit is still in use. Anyone who has ever tried to make a phone call at a busy time (say, early morning on Mother\u2019s Day or at midnight on New Year\u2019s Eve) and received an \u201call circuits are busy\u201d recording has experienced congestion on an inefficient circuit-switched phone network.<\/p>\r\n

    But unlike circuit-switched counterparts, Internet networks are packet-switched networks, which can be more efficient. Since we can slice conversations up into packets, we can squeeze them into smaller spaces. If there are pauses in a conversation or someone\u2019s on hold, applications don\u2019t hold up the network. And that creates an opportunity to use the network\u2019s available capacity for other users. The trade-off is one that swaps circuit switching\u2019s quality of service (QoS) with packet switching\u2019s efficiency and cost savings. Try to have a VoIP call when there\u2019s too much traffic on a portion of the network and your call quality will drop. But packet switching quality is getting much better. Networking standards are now offering special features, such as \u201cpacket prioritization,\u201d that can allow voice packets to gain delivery priority over packets for applications like e-mail, where a slight delay is OK.<\/p>\r\n

    When voice is digitized, \u201ctelephone service\u201d simply becomes another application that sits on top of the Internet, like the Web, e-mail, or FTP. VoIP calls between remote offices can save long distance charges. And when the phone system becomes a computer application, you can do a lot more. Well-implemented VoIP systems allow users\u2019 browsers access to their voice mail inbox, one-click video conferencing and call forwarding, point-and-click conference call setup, and other features, but you\u2019ll still have a phone number, just like with POTS.<\/p>\r\n\r\n<\/div>\r\n \r\n\r\n<\/div>\r\n

    \r\n

    What Connects the Routers and Computers?<\/h2>\r\n

    Routers are connected together, either via cables or wirelessly. A cable connecting a computer in a home or office is probably copper (likely what\u2019s usually called an Ethernet cable), with transmissions sent through the copper via electricity. Long-haul cables, those that carry lots of data over long distances, are usually fiber-optic lines\u2014glass lined cables that transmit light (light is faster and travels farther distances than electricity, but fiber-optic networking equipment is more expensive than the copper-electricity kind). Wireless transmission can happen via Wi-Fi (for shorter distances), or cell phone tower or satellite over longer distances. But the beauty of the Internet protocol suite (TCP\/IP) is that it doesn\u2019t matter what the actual transmission media are. As long as your routing equipment can connect any two networks, and as long as that equipment \u201cspeaks\u201d IP, then you can be part of the Internet.<\/p>\r\n

    In reality, your messages likely transfer via lots of different transmission media to get to their final destination. If you use a laptop connected via Wi-Fi, then that wireless connection finds a base station, usually within about three hundred feet. That base station is probably connected to a local area network (LAN) via a copper cable. And your firm or college may connect to fast, long-haul portions of the Internet via fiber-optic cables provided by that firm\u2019s Internet service provider (ISP).<\/p>\r\n

    Most big organizations have multiple ISPs for redundancy, providing multiple paths in and out of a network. This is so that if a network connection provided by one firm goes down, say an errant backhoe cuts a cable, other connections can route around the problem (see Figure 12.1<\/a>).<\/p>\r\n

    In the United States (and in most deregulated telecommunications markets), Internet service providers come in all sizes, from smaller regional players to sprawling international firms. When different ISPs connect their networking equipment together to share traffic, it\u2019s called peering<\/a><\/span>. Peering usually takes place at neutral sites called Internet exchange points<\/em> (IXPs), although some firms also have private peering points. Carriers usually don\u2019t charge one another for peering. Instead, \u201cthe money is made\u201d in the ISP business by charging the end-points in a network\u2014the customer organizations and end users that an ISP connects to the Internet. Competition among carriers helps keep prices down, quality high, and innovation moving forward.<\/p>\r\n\r\n

    \r\n
    \r\n

    Finance Has a Need for Speed<\/h4>\r\n

    When many folks think of Wall Street trading, they think of the open outcry pit at the New York Stock Exchange (NYSE). But human traders are just too slow for many of the most active trading firms. Over half of all U.S. stock trades and a quarter of worldwide currency trades now happen via programs that make trading decisions without any human intervention (Timmons, 2006). There are many names for this automated, data-driven frontier of finance\u2014algorithmic trading, black-box trading, or high-frequency trading. And while firms specializing in automated, high-frequency trading represent only about 2 percent of the trading firms operating in the United States, they account for about three quarters of all U.S. equity trading volume (Iati, 2009).<\/p>\r\n

    Programmers lie at the heart of modern finance. \u201cA geek who writes code\u2014those guys are now the valuable guys\u201d says the former head of markets systems at Fidelity Investments, and that rare breed of top programmer can make \u201ctens of millions of dollars\u201d developing these systems (Berenson, 2009). Such systems leverage data mining and other model-building techniques to crunch massive volumes of data and discover exploitable market patterns. Models are then run against real-time data and executed the instant a trading opportunity is detected. (For more details on how data is gathered and models are built, see Chapter 11 \u201cThe Data Asset: Databases, Business Intelligence, and Competitive Advantage\u201d<\/a>.)<\/p>\r\n

    Winning with these systems means being quick\u2014very quick. Suffer delay (what techies call latency<\/em>) and you may have missed your opportunity to pounce on a signal or market imperfection. To cut latency, many trading firms are moving their servers out of their own data centers and into colocation facilities<\/em>. These facilities act as storage places where a firm\u2019s servers get superfast connections as close to the action as possible. And by renting space in a \u201ccolo<\/em>,\u201d a firm gets someone else to manage the electrical and cooling issues, often providing more robust power backup and lower energy costs than a firm might get on its own.<\/p>\r\n

    Equinix, a major publicly traded IXP and colocation firm with facilities worldwide, has added a growing number of high-frequency trading firms to a roster of customers that includes e-commerce, Internet, software, and telecom companies. In northern New Jersey alone (the location of many of the servers where \u201cWall Street\u201d trading takes place), Equinix hosts some eighteen exchanges and trading platforms as well as the NYSE Secure Financial Transaction Infrastructure (SFTI) access node.<\/p>\r\n

    Less than a decade ago, eighty milliseconds was acceptably low latency, but now trading firms are pushing below one millisecond into microseconds (Schmerken, 2009). So it\u2019s pretty clear that understanding how the Internet works, and how to best exploit it, is of fundamental and strategic importance to those in finance. But also recognize that this kind of automated trading comes with risks. Systems that run on their own can move many billions in the blink of an eye, and the actions of one system may cascade, triggering actions by others.<\/p>\r\n

    The spring 2010 \u201cFlash Crash\u201d resulted in a nearly 1,000-point freefall in the Dow Jones Industrial Index, it\u2019s biggest intraday drop ever. Those black boxes can be mysterious\u2014weeks after the May 6th event, experts were still parsing through trading records, trying to unearth how the flash crash happened (Daimler & Davis, 2010). Regulators and lawmakers recognize they now need to understand technology, telecommunications, and its broader impact on society so that they can create platforms that fuel growth without putting the economy at risk.<\/p>\r\n\r\n<\/div>\r\n \r\n\r\n<\/div>\r\n

    \r\n
    \r\n

    Watching the Packet Path via Traceroute<\/h4>\r\n

    Want to see how packets bounce from router to router as they travel around the Internet? Check out a tool called traceroute<\/em>. Traceroute repeatedly sends a cluster of three packets starting at the first router connected to a computer, then the next, and so on, building out the path that packets take to their destination.<\/p>\r\n

    Traceroute is built into all major desktop operating systems (Windows, Macs, Linux), and several Web sites will run traceroute between locations (traceroute.org and visualroute.visualware.com are great places to explore).<\/p>\r\n

    The message below shows a traceroute performed between Irish firm VistaTEC and Boston College. At first, it looks like a bunch of gibberish, but if we look closely, we can decipher what\u2019s going on.<\/p>\r\n\r\n

    \r\n
    \r\n

    Figure 12.5<\/span><\/p>\r\n

    \r\n\"a\r\n<\/a><\/p>\r\n\r\n<\/div>\r\n<\/div>\r\n

    The table above shows ten hops, starting at a domain in vistatec.ie and ending in 136.167.9.226 (the table doesn\u2019t say this, but all IP addresses starting with 136.167 are Boston College addresses). The three groups of numbers at the end of three lines shows the time (in milliseconds) of three packets sent out to test that hop of our journey. These numbers might be interesting for network administrators trying to diagnose speed issues, but we\u2019ll ignore them and focus on how packets get from point to point.<\/p>\r\n

    At the start of each line is the name of the computer or router that is relaying packets for that leg of the journey. Sometimes routers are named, and sometimes they\u2019re just IP addresses. When routers are named, we can tell what network a packet is on by looking at the domain name. By looking at the router names to the left of each line in the traceroute above, we see that the first two hops are within the vistatec.ie network. Hop 3 shows the first router outside the vistatec.ie network. It\u2019s at a domain named tinet.net, so this must be the name of VistaTEC\u2019s Internet service provider since it\u2019s the first connection outside the vistatec.ie network.<\/p>\r\n

    Sometimes routers names suggest their locations (oftentimes they use the same three character abbreviations you\u2019d see in airports). Look closely at the hosts in hops 3 through 7. The subdomains dub20, lon11, lon01, jfk02, and bos01 suggest the packets are going from Dublin, then east to London, then west to New York City (John F. Kennedy International Airport), then north to Boston. That\u2019s a long way to travel in a fraction of a second!<\/p>\r\n

    Hop 4 is at tinet.net, but hop 5 is at cogentco.com (look them up online and you\u2019ll find out that cogentco.com, like tinet.net, is also an ISP). That suggests that between those hops peering is taking place and traffic is handed off from carrier to carrier.<\/p>\r\n

    Hop 8 is still cogentco.com, but it\u2019s not clear who the unnamed router in hop 9, 38.104.218.10, belongs to. We can use the Internet to sleuth that out, too. Search the Internet for the phrase \u201cIP address lookup\u201d and you\u2019ll find a bunch of tools to track down the organization that \u201cowns\u201d an IP address. Using the tool at whatismyip.com, I found that this number is registered to PSI Net, which is now part of cogentco.com.<\/p>\r\n

    Routing paths, ISPs, and peering all revealed via traceroute. You\u2019ve just performed a sort of network \u201cCAT scan\u201d and looked into the veins and arteries that make up a portion of the Internet. Pretty cool!<\/p>\r\n

    If you try out traceroute on your own, be aware that not all routers and networks are traceroute friendly. It\u2019s possible that as your trace hits some hops along the way (particularly at the start or end of your journey), three \u201c*\u201d characters will show up at the end of each line instead of the numbers indicating packet speed. This indicates that traceroute has timed out on that hop. Some networks block traceroute because hackers have used the tool to probe a network to figure out how to attack an organization. Most of the time, though, the hops between the source and destination of the traceroute (the steps involving all the ISPs and their routers) are visible.<\/p>\r\n

    Traceroute can be a neat way to explore how the Internet works and reinforce the topics we\u2019ve just learned. Search for traceroute tools online or browse the Internet for details on how to use the traceroute command built into your computer.<\/p>\r\n\r\n<\/div>\r\n \r\n\r\n<\/div>\r\n

    \r\n
    \r\n

    There\u2019s Another Internet?<\/h4>\r\n

    If you\u2019re a student at a large research university, there\u2019s a good chance that your school is part of Internet2. Internet2 is a research network created by a consortium of research, academic, industry, and government firms. These organizations have collectively set up a high-performance network running at speeds of up to one hundred gigabits per second to support and experiment with demanding applications. Examples include high-quality video conferencing; high-reliability, high-bandwidth imaging for the medical field; and applications that share huge data sets among researchers.<\/p>\r\n

    If your university is an Internet2 member and you\u2019re communicating with another computer that\u2019s part of the Internet2 consortium, then your organization\u2019s routers are smart enough to route traffic through the superfast Internet2 backbone. If that\u2019s the case, you\u2019re likely already using Internet2 without even knowing it!<\/p>\r\n\r\n<\/div>\r\n \r\n\r\n<\/div>\r\n

    \r\n
    \r\n

    Key Takeaways<\/span><\/p>\r\n\r\n<\/header>\r\n

    \r\n