How to monitor and handle network Traffic ios

monitor network traffic ios simulator and how to monitor network traffic ios and ios intercept network traffic and capture network traffic ios
Dr.KiranArora Profile Pic
Dr.KiranArora,Canada,Teacher
Published Date:27-10-2017
Your Website URL(Optional)
Comment
Testing and Manipulating Network Traffi c The wrox.com code downloads for this chapter are found at www.wrox.com/WileyCDA/ WroxTitle/Professional-iOS-Network-Programming-Connecting-the-Enterprise-to- the-iPhone-and-iPad.productCd-1118362403.html on the Download Code tab. The code is in the Chapter 9 download and individually named according to the names throughout the chapter. You make mistakes. This is an inesc apable fact of life that everybody deals with every day. Because you and every other person in the world make mistakes, the software you write also has mistakes. Because of this it is essential to diagnose software behavior, fi nd the mistakes, correct them, and try to avoid them in the future. When writing networked applications, many layers of software and hardware are in between each component of the system. It is often necessary to observe the interaction between these components to get a complete and accurate picture of what happens at a higher level, so you can better discover any existing mistakes. This chapter describes methods to observe these network interactions, manipulate them, and simulate real-world conditions in them. Observing network interactions gives you an accurate picture of which requests leave the device and what data is received. Manipulating network traffi c allows you to create situations in a development lab that occur only when consumers use the app. Simulating network conditions also enables you to validate the behavior of the app under varying network conditions. c09.indd 191 c09.indd 191 05/10/12 3:50 PM 05/10/12 3:50 PM192 CHAPTER 9 TESTING AND MANIPULATING NETWORK TRAFFIC ❘ OBSERVING NETWORK TRAFFIC When writing a networked application, you do not have total control over the packets transmitted from or received by the device. Many layers of software and hardware exist between your code on the device and the code on a remote server. Because the interactions between your code and the underlying net- work layers may be poorly documented or poorly understood, you sometimes must examine the raw data transmitted from the device to know without a doubt what your app is sending. Likewise, similar layers intervene between the server and your app, and you sometimes must know the exact data received from the server. For example, if your app adds HTTP headers to a request, you may need to know exactly how iOS is further manipulating those headers and what it eventually transmits to the server. The act of observing network traffi c is called sniffi ng or packet analysis. Packet analyzers have been around since the early days of networking and are available for almost every type of physical inter- connect and protocol. This section focuses on sniffi ng Ethernet and Wi-Fi connections that use TCP transport and HTTP application protocols from a development system running OS X Lion. Sniffi ng Hardware Before you can start capturing network traffi c from an iOS device, you must fi rst have a network topol- ogy that can facilitate packet capture. The computer running the sniffi ng software must be on the same network as the Wi-Fi device, or the packets from the Wi-Fi network must be propagated to the sniffi ng laptop. Therefore, you may need to do some hardware shuffl ing to capture traffi c from a device. NOTE No special hardware or network confi guration is required to capture pack- ets from the iOS Simulator. If you need to capture these packets, you can use the sniffi ng software listed in the next section to listen on the loopback device (lo0) or the interface used to connect to the network. The fi rst suggested confi guration, shown in Figure 9-1, iOS uses a Wi-Fi network shared by both the sniffi ng com- Device puter and the iOS device. In the common Wi-Fi confi guration, the iOS device and sniffi ng computer pair with a Wi-Fi access point. The Wi-Fi adapter on the sniffi ng computer receives all net- work packets transmitted over the Wi-Fi network. The sniffi ng software must be confi gured to run in monitor Wi-Fi Access Router Internet mode so that the low-level Wi-Fi drivers propagate all Point packets to the sniffi ng software. In some corporate net- works with heavy Wi-Fi coverage, the mobile device and the sniffi ng computer may pair to different access points on different channels. This can occur even when the device and computer are in close proximity because the two sys- tems have different rules controlling which access points to Sniffng prefer and how aggressively to switch access points. If Laptop the device and computer pair to different networks, the computer may not see Wi-Fi traffi c from the device. FIGURE 9-1 c09.indd 192 c09.indd 192 05/10/12 3:50 PM 05/10/12 3:50 PM Wi-Fi Wi-FiObserving Network Traffi c 193 ❘ A second confi guration, shown in iOS Figure 9-2, uses the Internet-sharing Device feature of OS X to make the sniffi ng laptop act as the Wi-Fi access point. In this confi guration you need to connect the sniffi ng laptop to a wired Ethernet network and enable Internet sharing in OS X to share the Ethernet network with Sniffing Ethernet Router Internet Wi-Fi users. You then need to confi gure Laptop Network the iOS device to join the Wi-Fi network FIGURE 9-2 created by the sniffi ng laptop. Each network packet sent from the device to the Internet traverses the Wi-Fi and Ethernet interface of the laptop. Using this confi guration you can observe client-server traffi c as well as peer-to-peer traffi c such as the traffi c generated by Game Kit. Sniffi ng Software There are many network sniffers available for OS X; some free like Wireshark (discussed later) and Packet Peeper (see http://sourceforge.net/projects/packetpeeper/), as well as some shareware like Cocoa Packet Analyzer (http://www.tastycocoabytes.com/cpa). A command-line packet sniffer, tcpdump, is bundled with OS X and is the foundation for most other sniffers available for OS X. tcpdump can capture the network traffi c from an interface, fi lter it according to criteria you specify, display the traffi c, and save the traffi c trace to a log fi le. The traffi c display of tcpdump is diffi cult to decipher, but many packet analyzers leverage the fi ltering syntax; making it worthwhile to learn. Capturing with tcpdump The sniffi ng needs of network engineers vary greatly from those of app developers. Network engineers need to see every bit transmitted from the device, and this level of detail obscures the HTTP request data most important to app developers. This section looks at the fi lters commonly used by app developers to analyze networking traffi c generated by an app. If you run tcpdump from the command line with no fi lters, you see a fl ood of packets. This fl ood usually obscures the traffi c that you want to see: the traffi c between your app and its server. To avoid this you should apply fi ltering. The most basic fi lter is fi ltering by host, which causes tcpdump to ignore all traffi c except for that with a specifi c host. The following code snippet shows a fi lter tcpdump command that fi lters out all traffi c except to or from the host at address 192.168.1.50. sudo tcpdump host 192.168.1.50 NOTE The sudo command will prompt you for a password. You should use the password for the currently logged in account. c09.indd 193 c09.indd 193 05/10/12 3:50 PM 05/10/12 3:50 PM Wi-Fi194 CHAPTER 9 TESTING AND MANIPULATING NETWORK TRAFFIC ❘ The host fi lter can use either an IP address or a DNS host or domain name. If you specify a DNS domain, any traffi c to any host in that domain will be captured. You can also fi lter traffi c from mul- tiple hosts by using logical operators to include other criteria. The following code captures traffi c to host 192.168.1.50 and 10.1.2.25. sudo tcpdump host 192.168.1.50 or 10.1.2.25 Depending on your network confi guration, it may be necessary to fi lter for traffi c destined for an entire subnet. The following code snippet fi lters traffi c to the 192.168.1 subnet. sudo tcpdump net 192.168.1.0/24 Another common practice is to fi lter packets by the TCP or UDP port numbers used by the con- nection. tcpdump uses names defi ned in /etc/services to map a TCP service port name to a port number. The following code shows two equivalent commands to fi lter for HTTP traffi c. sudo tcpdump port http sudo tcpdump port 80 Remember that the value http is used to look up the port number, not to detect the protocol used in the connection. Therefore, if you use the HTTP protocol over a TCP connection using a port other than 80, the preceding fi lters cannot capture that traffi c. The fi lter criteria can be combined to focus the capture on a specifi c host and port by using logical operators. The following snippet captures only packets on ports 80 and 8080 for host 192.168.1.50. sudo tcpdump host 192.168.1.50 and \(port 80 or port 443\) Using the and and or operators along with separating parentheses, you can fi lter your captured data to eliminate extraneous traffi c that might obscure problems. The backslash (\) characters in the fi lter expression prevent the command shell from interpreting the parentheses. When using tcpdump fi lter syntax within a graphical program, these backslash characters must be omitted. Inversely, be careful not to over-fi lter and remove important data. tcpdump can be used to run an extended capture of network traffi c and save it to a capture fi le for later analysis. The graphical sniffer, Wireshark, described in the next section, “Capturing with Wireshark,” can import an existing capture fi le so that you can drill into the data using a friendlier interface. The following snippet can capture all traffi c on port 80 and save it to a fi le named http-capture.trace. sudo tcpdump –s 1514 port 80 –w http-capture.trace The –s 1514 argument instructs tcpdump to capture the fi rst 1514 bytes of the packet. This cap- tures the most common Ethernet packet size; however, if your network uses jumbo-sized packets, you may need to increase this value. c09.indd 194 c09.indd 194 05/10/12 3:50 PM 05/10/12 3:50 PMObserving Network Traffi c 195 ❘ Capturing with Wireshark Wireshark (http://www.wireshark.org) is a free, cross-platform graphical network sniffer avail- able for most major operating systems. It can capture new traces or analyze traces captured earlier with tcpdump. On OS X, Wireshark requires that X11 also be installed. The installation process modifi es the permissions of a handful of device fi les so that the installing user can capture data from those devices without being a super-user. When you start Wireshark you see a helpful start page, as shown in Figure 9-3, where you can start a trace directly against an interface, set trace options, or open an existing trace fi le. Select options to configure the capture filters FIGURE 9-3 If you start a trace directly on an interface, you see a fl ood of packets that are probably not helpful. If you start a trace by using the Capture-Options menu entry, you can tune your capture to fi t your needs. NOTE Because Wireshark is such a powerful tool, it has functions that you will probably never use as a developer; don’t let that stop you from experimenting with the application to discover features that may be benefi cial. If you confi g- ure yourself into a corner where things stop working, close the application and restart it; nothing will be permanently broken. c09.indd 195 c09.indd 195 05/10/12 3:50 PM 05/10/12 3:50 PM196 CHAPTER 9 TESTING AND MANIPULATING NETWORK TRAFFIC ❘ Using the Capture Options dialog box, as shown in Figure 9-4, the Interface fi eld allows you to select an interface to capture. Table 9-1 lists three common network interfaces. Interface Field Turn on monitor mode for shared Wi-Fi monitoring Filter Field Live Update Settings FIGURE 9-4 TABLE 9-1: Network Interface Descriptions INTERFACE NAME INTERFACE TYPE DESCRIPTION en0 Ethernet The wired Ethernet port on an OS X laptop en1 Wi-Fi The default Airport interface in OS X lo0 Loopback The local loopback interface used if a program connects to localhost or 127.0.0.1 Use the capture fi lter fi eld to specify which packets to capture using the same syntax as the tcpdump command. The sniffer captures only packets going to host www.nasa.gov (refer to Figure 9-4). If you are sniffi ng your app’s packets using the common Wi-Fi topology (refer to Figure 9-1) you need to enable monitor mode. Monitor mode confi gures the Wi-Fi adapter to pass all network c09.indd 196 c09.indd 196 05/10/12 3:50 PM 05/10/12 3:50 PMObserving Network Traffi c 197 ❘ packets received on the Wi-Fi adapter up to the software driver. Without this option enabled, the packets not addressed to the sniffi ng computer are ignored by the Wi-Fi hardware. Your mileage may vary depending on your wireless network confi guration, operating system version, and version of Wireshark. Wireshark is available for OS X, Linux, and Windows. Each platform provides slightly different capabilities so you can use a different OS if necessary to get the perfect confi guration for your network. The live update settings instruct Wireshark to continually update the display as packets are cap- tured. This feature is useful to determine if you have specifi ed the fi lter correctly and to easily detect when you have captured suffi cient data; however, on slower machines it may impact the perfor- mance of the application enough to cause it to drop packets. Pressing the Start button on this dialog initiates a capture session. With live updating enabled, you see packet headers appear in the Captured Packet list as they are captured. Figure 9-5 shows an example capture of the network packets produced when the VideoDownloader app, described in Chapter 3, “Making Requests,” was run on an iPhone. The Packet Decomposition panel exposes the values for each protocol layer for the packet selected in the Captured Packets List. The packet is decomposed into three layers: Ethernet II, Internet Protocol, and Transmission Control Protocol (refer to Figure 9-5). Display Filter Captured Packets Packet Decomposition Packet Hex Dump FIGURE 9-5 fo c09.indd 197 c09.indd 197 05/10/12 3:50 PM 05/10/12 3:50 PM198 CHAPTER 9 TESTING AND MANIPULATING NETWORK TRAFFIC ❘ The Packet Hex Dump area displays the hexadecimal values for each byte in the selected packet and an ASCII conversion of those hex values. If you drill down into a protocol layer in the Packet Decomposition panel the selected portion of the packet is highlighted in the hex dump. One incredibly helpful feature of Wireshark is the capability to follow a TCP stream. In a typical packet dump on a moderately active machine, you have multiple TCP streams and HTTP conversa- tions occurring concurrently with their packets intermingled. To follow a TCP stream, Ctrl+click on a packet from the stream to activate the packet menu, as shown in Figure 9-6. Follow TCP Stream for full HTTP conversation FIGURE 9-6 Select the Follow TCP Stream option of the packet context menu to show the stream trace (see Figure 9-7). The Follow TCP Stream dialog displays the contents of each packet of the stream as one continuous set of data. The outbound and inbound data are shaded differently so that you can easily distinguish the packet direction. In Figure 9-7 the data outbound from the phone has a dark background and the inbound data has a white background. Notice that the response data appears to be gibberish because the Content-Encoding of the payload is gzip, and it must be decompressed to reveal its actual contents. fo c09.indd 198 c09.indd 198 05/10/12 3:50 PM 05/10/12 3:50 PMObserving Network Traffi c 199 ❘ FIGURE 9-7 Wireshark has a solution to the problem of compressed data. Figure 9-8 shows the contents of the eighth packet selected. Wireshark has deduced that this packet is the response to an HTTP request and that it has XML data in the response body. Therefore it provides additional diagnostic data about the entire payload. The Packet Reassembly Views contain the payload of the response pieced together from any subsequent network packets that contain the payload. If the HTTP response were compressed, Wireshark would decompress it. The Uncompressed Entity Body view displays the con- tents of the response after decompression. c09.indd 199 c09.indd 199 05/10/12 3:50 PM 05/10/12 3:50 PM200 CHAPTER 9 TESTING AND MANIPULATING NETWORK TRAFFIC ❘ Packet Reassembly Views FIGURE 9-8 Wireshark is a powerful tool that should be in every network developer’s tool box. It can be extended with modules, called dissectors, which parse many industry-standard protocols, but you can also develop your own dissectors to parse your own custom protocols. If built from source, Wireshark can be used to decrypt SSL connections under certain circumstances. By using Wireshark, you can exam- ine every bit and packet transmitted from the device for any networking protocol, which is helpful if you are doing custom protocol development or using non-HTTP based communications. The next section provides a simpler, but less powerful, way to capture and decode network traffi c within your development environment. MANIPULATING NETWORK TRAFFIC Network packet capture tools provide a way to observe network traffi c, but sometimes you need to do more than observe. Luckily there is a common network component, an HTTP proxy, which developers can leverage to manipulate HTTP and HTTPS requests. Some of the uses of HTTP manipulation include ➤ Error simulation — You can intercept a response and change the status code on the response to an error status and optionally change the payload to represent an error. This capability enables you to test how your app responds to error responses from the server without needing to actually invoke an error. c09.indd 200 c09.indd 200 05/10/12 3:50 PM 05/10/12 3:50 PMManipulating Network Traffi c 201 ❘ ➤ Future state simulation — If you know that a future version of the server will provide differ- ent responses from the current server, you can test old versions of the app against the altered protocol. ➤ Server validation — You can modify requests to the server to validate responses based on data that may be diffi cult to duplicate on a device without writing Objective-C code. ➤ Security validation — Security personnel can validate the behavior of your app or an off- the-shelf app for secure network interactions. ➤ Reverse engineering — You can use a proxy to intercept and decode any HTTP request to discover how an app communicates with its servers. Network proxies are appliances that usually reside at the perimeter of a secured network and act as a go-between for every request sent to a server. Many large enterprises deploy network proxies to provide content fi ltering, access control, virus protection, and response caching for personal computers within their network. The HTTP client, typically a browser, must be confi gured to use the appliance as a proxy; otherwise, it has no access to servers outside of the protected network. Figure 9-9 illustrates the sequence of activities for an HTTP request and response that traverses a proxy server. Client HTTP Proxy Server TCP Connection HTTP Request TCP Connection Modified HTTP Request HTTP Response Modified HTTP Response FIGURE 9-9 c09.indd 201 c09.indd 201 05/10/12 3:50 PM 05/10/12 3:50 PM202 CHAPTER 9 TESTING AND MANIPULATING NETWORK TRAFFIC ❘ When a client makes an HTTP request, the client fi rst establishes a TCP connection to the proxy server and sends the HTTP request to the proxy. The proxy applies its processing rules to the request, which may deny the request because it is destined for a blacklisted site or because the request itself has unauthorized content. If the proxy is a caching proxy, it may short-circuit the request and return a response cached from an earlier request to the same destination. If the request is acceptable, the proxy establishes a TCP connection with the true target host specifi ed in the request and then transmits the HTTP request to the target host. If the target host responds, then the HTTP response is received by the proxy, and additional processing rules are applied. For example, the response may be scanned for viruses or cached. If the response is acceptable, it is passed back to the requesting client. A proxy can handle HTTPS requests in a couple of different ways. First, it may just deny all HTTPS requests, but this behavior is uncommon. Alternatively, some proxy confi gurations pass HTTPS requests through unaltered and unfi ltered. The third possible behavior is that the proxy establishes an HTTPS connection with the client and provides an SSL certifi cate that appears to be from the target host but is signed with the proxy’s Certifi cate Authority (CA) certifi cate. The proxy is essentially performing a man-in-the-middle attack on the request, but instead of nefarious purposes, the attack is intended to protect the enterprise. For this approach to work, the client must have the proxies’ CA certifi cate installed in its keychain. If the request is allowed, the proxy establishes an SSL connection with the target host and transmits the request securely. There are many proxy software and hardware packages available to network engineers. These packages are designed for network engineers and have limited usefulness to app developers. Charles (http://www.charlesproxy.com) is a reasonably-priced proxy software package designed for developers. It is a desktop application that performs proxy services for any HTTP client. Charles allows the developer to manually intercept a request and modify the request or response. It can also be confi gured to automatically perform the same types of modifi cations on requests. If you use an HTTP proxy to manipulate network traffi c, you can manipulate only HTTP and HTTPS requests. If your app uses another protocol, a proxy will not be of assistance. The following subsections describe the use of Charles to intercept and manipulate HTTP requests and responses. Setting Up Charles To use Charles, the OS X machine and the iOS device must be on the same network. They do not need to be on the same subnet, but one should be able to ping the other. The iOS device must be on a Wi-Fi network because iOS does not apply proxy settings to WWAN connections. To set-up Charles to capture traffi c via a proxy, perform the following steps: 1. When you run Charles, it confi gures the proxy settings on the OS X machine by default. This behavior clutters the data captured from the device, so you need to disable the OS X proxy. To do this, select the Proxy Settings menu, as shown in Figure 9-10. c09.indd 202 c09.indd 202 05/10/12 3:50 PM 05/10/12 3:50 PMManipulating Network Traffi c 203 ❘ Select Proxy Settings FIGURE 9-10 2. A settings dialog appears, as shown in Figure 9-11. Select the Mac OS X tab, and uncheck all the options on that view; then press OK. Charles then removes the proxy confi guration from all active network interfaces. Disable Mac OS X Proxy and Enable Mac OS X Proxy startup FIGURE 9-11 3. Next you must confi gure the iOS device to route all its HTTP traffi c through the proxy. First, determine the IP address of the machine running Charles. On that machine, open a Terminal window and execute the ifconfig command. The following snippet shows part of the output. ifconfig lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 … en1: flags=8863UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST mtu 1500 ether e0:f8:47:34:98:8a inet6 fe80::e2f8:47ff:fe34:988a%en1 prefixlen 64 scopeid 0x5 inet 192.168.1.34 netmask 0xffffff00 broadcast 192.168.1.255 media: autoselect status: active c09.indd 203 c09.indd 203 05/10/12 3:50 PM 05/10/12 3:50 PM204 CHAPTER 9 TESTING AND MANIPULATING NETWORK TRAFFIC ❘ 4. Look for the confi guration of the en1 interface. The IP address will be provided in that confi guration data; in this case the IP address is 192.168.1.34. The interface you use depends on your network topology. If the machine running Charles only has an Ethernet interface then you need to use en0 as the interface. 5. Remembering this value, go to the iPhone or iPad and start the Settings app and the Wi-Fi Settings subsection. Tap on the blue disclosure indicator on the table cell of the active Wi-Fi network. At the bottom of the subsequent detail view, as shown in Figure 9-12, there is a segmented control where you can enable manual HTTP proxy confi guration. FIGURE 9-12 6. Select the Manual option, and enter the IP address that was previ- ously in the server fi eld. The default port for Charles is port 8888. Press the back button in that view and the proxy settings are applied. If you leave these settings active on the phone, it will block all HTTP traffi c unless Charles is running at the specifi ed address, so don’t forget to reverse this setting when you complete your debugging session. This example uses the VideoDownloader app provided with Chapter 3, which downloads an RSS feed from NASA. When run with the proxy confi gured and recording data, the proxy captures a single HTTP transaction. Charles groups these transactions into a single line. If you select a transac- tion and the Structure tab above the transaction list, you can drill down into a request and examine the request and response in detail. Figure 9-13 shows the capture of a single request from the app caught by the proxy. View various parts of the request/response FIGURE 9-13 c09.indd 204 c09.indd 204 05/10/12 3:50 PM 05/10/12 3:50 PMManipulating Network Traffi c 205 ❘ HTTP Breakpoints Charles allows you to set a breakpoint on a URL so that you can i nterrupt and alter the request or response. You can have multiple breakpoints set on many different URLs. To set a breakpoint, perform the following steps: 1. Ctrl+click the transaction in the list that matches the URL of the transaction you want to catch. The resulting pop-up menu, shown in Figure 9-14, contains an option to set a breakpoint on that URL. 2. Select the Breakpoints option to enable a breakpoint on that URL. On a subsequent invocation of the VideoDownloader app, Charles can catch the request and display the breakpoint window, as shown in Figure 9-15. FIGURE 9-14 FIGURE 9-15 The request Overview panel provides summary information about the request that is extracted from the request. Some of the values are undefi ned because a response has not yet been received. If you select the Edit Request panel, you see the exact contents of the request that was sent by the device. On the Edit Request panel, as shown in Figure 9-16, you can manually manipulate the contents of the request. c09.indd 205 c09.indd 205 05/10/12 3:50 PM 05/10/12 3:50 PM206 CHAPTER 9 TESTING AND MANIPULATING NETWORK TRAFFIC ❘ FIGURE 9-16 You can use this panel to modify the URL, headers, query string, text of the request body, or the raw bytes of the request. If you modify the URL, Charles sends the request to a different URL than that speci- fi ed by the app. If you use this functionality, you can direct a single request to a test server to validate an older version of the apps behavior against a new server before deploying the server into production. You can also add, remove, or modify headers or the body in the request. This is helpful to validate the server’s response to different meta data or payload data in the request. If you press the Execute button, Charles forwards the request to the server. If a breakpoint is set on a URL, then Charles also interrupts the transaction and displays the edit request panel, as shown in Figure 9-17, when the response to the request is received from the server. For every breakpoint you receive two interruptions. FIGURE 9-17 c09.indd 206 c09.indd 206 05/10/12 3:50 PM 05/10/12 3:50 PMManipulating Network Traffi c 207 ❘ Using the response breakpoint panel, you can modify the HTTP response headers and body returned by the server. Like editing the request, all the content of the response may be altered. This is a powerful feature that allows you to validate an app’s response to erroneous responses or simulate edge conditions that would normally be diffi cult to reproduce in the service tier. If the app you test has short request timeout values, then intercepting requests with breakpoints may cause timeout errors in the app. Manual editing of requests or responses needs to be performed quickly, or by setting up a rewrite rule in Charles. Rewrite Rules Rewrite rules specify modifi cations to make to HTTP transactions automatically by Charles. A rewrite rule can be assigned to a set of URLs and contains a set of modifi cations to make to the request, response, or both. The modifi cations can be made to any part of the URL, header, or body. Each modifi cation is described as a text pattern and replacement text, which can be regular expressions. To add a rewrite rule select the Tools ➪ Rewrite menu option from Charles’ application menu. The Rewrite Settings window is shown in Figure 9-18. FIGURE 9-18 c09.indd 207 c09.indd 207 05/10/12 3:50 PM 05/10/12 3:50 PM208 CHAPTER 9 TESTING AND MANIPULATING NETWORK TRAFFIC ❘ Using this window you can add a new rule set, add target URLs to the rule set, and create new rules. Each rule describes a text manipulation to perform on the requests and responses that match the URL. To add a rule, click the Add button on the rule section. The Rewrite Rule defi nition dia- log, as shown in Figure 9-19, allows you to defi ne the following: ➤ The part of the message to modify including headers, query parameters, URL, or body ➤ The phase of the transaction to which the rule applies: the request or the response ➤ The text or regular expression to match against ➤ The substitution text FIGURE 9-19 In Figure 9-19 the rule matches any occurrence of the text NASA in the response body and replaces it with NNAASSAA. If you apply this rule and run the VideoDownloader app you see the modifi ed text in the descriptions of the videos provided by the RSS feed. This capability is helpful in quickly applying modifi cations to the HTTP data so that complex edge conditions or error scenarios can be simulated to validate the service tier or app. Charles has many other features that you can use to manipulate the HTTP conversation between your app and a server. You can map requests to local fi les or other remote servers, which is helpful if the changes to a response are more complex than what can be accomplished with text replacement. c09.indd 208 c09.indd 208 05/10/12 3:50 PM 05/10/12 3:50 PMSimulating Real-World Network Conditions 209 ❘ You can also intercept and modify HTTPS requests with Charles. To enable HTTPS decryption you must confi gure Charles, using the Proxy Settings SSL panel, to enable specifi c URLs for SSL decryption. You also must install Charles’ CA certifi cate on the iOS device so that the device accepts the SSL certifi cates signed by Charles. The Charles CA certifi cate may be downloaded from www.charlesproxy.com/charles.crt. To install the certifi cate on your device, visit the download URL from the iOS device and iOS will confi rm the installation of the untrusted certifi cate. When installed, the iOS device accepts other SSL certifi cates signed by Charles. Before SSL decryption is confi gured, the transaction contents displayed are cipher-text, which is unreadable. After successful confi guration, the transaction results display as clear, readable text. This feature is invaluable for observing SSL connections from your app. WARNING Do not leave the Charles certifi cate installed on a device used for nondevelopment activities. The presence of a rogue CA certifi cate can expose you to a man-in-the-middle attack on public networks. Using a proxy to intercept and modify HTTP requests is a powerful tool for simulating or generating errors to validate your application’s behavior. Proxies are limited to intercepting only HTTP traffi c. SIMULATING REAL-WORLD NETWORK CONDITIONS Network packet capture and HTTP proxy tools are excellent at providing visibility to network traf- fi c. Another tool that all iOS developers should have in their toolbox and be familiar with is a network traffi c shaper to simulate slow or unreliable networks. Using a traffi c shaper to degrade network performance can help you identify problems in your app. Problem areas that can be identifi ed include: ➤ Over-aggressive timeouts — If you have set timeout values too low, testing the app on a degraded network highlights operations that would normally succeed but are aborted because of a timer expiration. ➤ Missing error handling — If you have timeouts occurring but the code to handle the time- out is missing or defective, running the app on a network that triggers the timeouts can identify those defects. ➤ User interface freezing — If your app is inadvertently making network calls on the main thread, running on a degraded network can help you detect the problem. ➤ User confusion — Running the app on a slow network during usability testing can illumi- nate areas where the app may not freeze but the user may be confused about what the app is doing when waiting for a response. These defects are usually resolved by user interface changes that inform the user of the activity performed by the app. c09.indd 209 c09.indd 209 05/10/12 3:50 PM 05/10/12 3:50 PM210 CHAPTER 9 TESTING AND MANIPULATING NETWORK TRAFFIC ❘ ➤ Cache implementation validation — It can be diffi cult to quantify the improvement provided by data caching when running your app on a high-speed network. Using a traffi c shaper you can quantify the improvement that your users can expect to see when caching is implemented. OS X Lion provides a great traffi c shaper called Network Link Conditioner (NLC). NLC interacts with the low-level network interface drivers of OS X and throttles the speed of every interface on the machine running it. It provides the ability to independently change the bandwidth, latency, and packet loss rate of both the received and transmitted data. NLC can also apply a delay to DNS responses. NLC comes with several predefi ned network profi les that match common network types, such as Wi-Fi, 3G, and EDGE networks. Figure 9-20 shows the profi le for a good 3G network. You can also defi ne your own profi les if you need to test on networks with other types of behavior. The performance experienced through the preconfi gured profi les is somewhat optimistic when compared to real-world networks; therefore, it may be necessary to apply settings slower than described by the default profi les. FIGURE 9-20 The NLC installation package is delivered as part of the XCode installation but not installed by default. Instead, a folder is written to /Applications/Utilities/Network Link Conditioner that contains the preference pane. Double-click the Network Link Conditioner.prefPane fi le to install the preference pane in your OS X System Preferences application. When installed, you can access NLC via the System Preferences. When using NLC, it must fi rst be unlocked and then turned on. The Profi le drop-down list allows you to select a packaged or custom network profi le to apply. Use the Manage Profi les button to cre- ate new profi les or edit the parameters of the packaged profi les. For NLC to be refl ected on iOS device communications, you need to run your device in a shared network topology (refer to Figure 9-2); otherwise the network packets from the device will bypass NLC. If you debug the app in the iOS Simulator, NLC actively shapes the network traffi c. XCode c09.indd 210 c09.indd 210 05/10/12 3:50 PM 05/10/12 3:50 PM

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.