Good morning, ladies and gentlemen. How many of you are here for the first time at WWDC? That's fantastic. It's great to see so many new faces every year. My name is Stuart Cheshire. And we're going to be talking about networking. I'm going to start by covering some topics that affect the performance of your app. There's hardly an app that exists today that doesn't make use of networking. And getting the best performance out of the network is really important.

We're going to cover some technologies here that help you get the best performance. We're also going to cover some tips and tricks and guidance about how to make the best use of Apple's APIs, a little bit of news about new technologies on the horizon, and then my colleague Jiten will go into detail on URLSession.

Let's start off with a state of the Internet update. Earlier this year, we hit a total of 4 billion people using the Internet. That's more than half of the world's population. And we're used to Internet usage doubling and doubling. Clearly when we passed halfway, the number of people on the Internet can't keep doubling, so that growth is slowing down but that doesn't mean Internet growth is slowing down.

There's a lot of growth in machine-to-machine communications, Internet of Things, Smart Homes. There's still a lot of growth in places like India and China. And there is a lot of people who have never owned a desktop computer who may never own a desktop computer. Their primary computing and communication device is their Smartphone.

And a lot of those Smartphones are still using 2G networks. I'm sure most of us in this room are fortunate enough to live in places and work in places where we build our apps where we have fast LTE networks. And that can be a handicap because if you build your app so it works well in LTE, it may perform very, very badly on 2G. One of your competitors, somewhere else in the world, who builds an app that works great on 2G is going to be fantastic on LTE. So we have a tool to help everybody mimic some of the properties of these slower networks and that's Network Link Conditioner.

You should build your app running Network Link Conditioner right from the start. Don't think you can add in performance at the end because it's too late. Always, always, always run and test your app using Network Link Conditioner and that way if you make a programming mistake that has horrible performance implications, you see it right away and you can fix it right away.

Use tools like Wireshark and tcptrace to understand the network performance of your app. It's a lot like using Instruments to look at memory and CPU usage. If you haven't seen tcptrace, it is a wonderful tool that produces graphs like this that let you see at a glance what's going on, on the network. If you want to learn more about that, check out the video from three years ago.

IPv6 usage continues to grow. Why is that important? It's important because IPv6 is shown to have better performance than IPv4. And if you care about performance, you want to make sure not just your app but the service your app is talking to support Native IPv6. Some places in the world are doing better in this respect than others. In the US, we're now up to 87% of mobile carriers offering IPv6. Other places like India are doing pretty well too. And let's focus a bit more on India.

Here is some data that the networking team at Apple gathered earlier this year about net TCP connection setup time and ongoing round-trip delay on cellular networks in India. The blue line is IPv6. And if we, for example, look at the 75th percentile, we can say 75% of TCP connections over v6 are set up in less than 150 milliseconds. The comparable number for IPv4 is worse than 325. It's more than twice as slow. So if you want fast, responsive applications for your users, get on IPv6 if you're not already.

Another technology that improves performance by reducing packet loss and retransmission is Explicit Congestion Notification. We've had this enabled by default in macOS and iOS for some years now so you don't need to do anything on your application to take advantage of this. Do make sure your service supports ECN. In a survey we did of the Alexa top million websites, we found last month we're now up to 77% of the Alexa top million services supporting ECN, which is a big improvement compared to a few years ago.

Another technology that helps improve performance and resilience of your connections is Multipath TCP. Quite often, the user may make a connection in their office on Wi-Fi and then they walk outside and they lose the Wi-Fi signal. Now with traditional TCP, the connection is broken. You have to reconnect. You have to start again. Multipath TCP makes its packet routing decisions on a per packet basis not per connection, so it can switch that connection live to a different interface.

We talked last year about how to enable this in your application. And, of course, check with your server operators to make sure your servers are supporting Multipath too. We recently did a survey of the mobile carriers that Apple works with around the world and right now 78% of their networks work with Multipath TCP. Only 22% of carriers are still blocking Multipath connections.

TCP Fast Open is a technology that lets you avoid the normal round-trip delay of the TCP connection set up. TCP Fast Open lets you put your initial data in with the TCP connection set up packets. You can check out more details of that from our video from three years ago. And check with your server operators to make sure that your servers support TCP Fast Open.

Now moving on to some new news. There is a technology that many of you will have heard of called Quick. Quick is a new transport protocol, the first serious candidate in 30 years for a successor to replace TCP. It started off as an experiment by some engineers at Google. That experiment proved successful. It has now been adopted as an IETF work in group item for standardization.

Apple engineers are participating in that. In fact, we have engineers right now at the Quick meeting taking place in Sweden. This is not yet ready for prime time. The standard is not finished, but Apple is working on it. As soon as it is ready, you can expect to see Apple API supporting that.

Continuing in the theme of performance, we observed some behavior that's very common. Lots and lots of websites and Internet services use pretty short lifetimes on their DNS records. And they do this because if a data center goes down, they want to be able to update the DNS and very rapidly direct traffic to a different data center.

The problem with this approach is you're paying a performance cost for something that almost never happens. Data centers very rarely go down. And what this means is every time a DNS address record is expired, your client has to spend another round-trip delay waiting for the response from the DNS server, which is the same as what it knew already last time.

So thinking about this, we realized and optimization we could do. If you pass the flag to opt into this new behavior, then when you do a DNS query, if we have a stale, expired answer in the cache, we will give that to you immediately while in parallel, at the same time, doing the normal DNS query we would have done anyway.

If the answer comes back the same, as we predict it will almost always, everything is fine, you just saved a round-trip time and got your connection started faster. If the answer comes back as a different address, we will then give another asynchronous notification to your client that there's a new address available which it should also try. And to make use of this, you have to use it in conjunction with Happy Eyeballs algorithm. That means your racing multiple connections in parallel.

You're trying IPv4, IPv6, multiple addresses, multiple interfaces. If that sounds like a lot of work and it's hard to get right, you're absolutely correct. It is a lot of work. Stay after the break and we will tell you about some new APIs that let you take advantage of this without doing all the hard work yourself.

Now moving on to some guidance. We have seen a common pattern that many developers use SCNetworkReachability as a preflight check. They want to predict the future. They want to know whether the next network operation they do will succeed or fail. And, unfortunately, predicting the future is always a hard thing to do. You may have connectivity now but two seconds from now the user has walked out of the building and you've lost the Wi-Fi signal. So there is no way to guarantee whether a future operation will succeed.

And we see this pattern where they check. The preflight says yes. They try it. They fail. They go back. They check again. This also is a lot of work, a lot of [inaudible], a lot of difficult things to get right including networks with proxies. We can handle that for you.

The better way to do this is just make a connection using the waitsForConnectivity option. You can learn more about that watching last year's video. What this means is if you want a connection, you tell the system I want a connection. Now if you can, later if not. If the device is in airplane mode, then when it's out of airplane mode your connection will succeed. That is much easier than building the retry loop yourself.

There is one case we've seen with developers which does make sense which is if you're going to have the user answer a lot of information in a form, you may not want to waste the user's time if you have good reason to believe that may later fail. If that is the use case you care about, stay after the break because we have a new way to do that that's much better.

Security remains important, as always. After ten years of using TLS 1.2, the Internet is now ready to move to its successor, TLS 1.3. It has a number of improved security features. It has reduced connection setup time, similar to TCP Fast Open. That standard is now final. The final draft was approved for publication by the Internet Engineering Steering Group earlier this year. We are waiting for the actual published document to come out of the RFC Editor. And when that does, we'll be turning on TLS 1.3 by default. Right now in your seed, it's not turned on by default.

You can use the instructions here on iOS or macOS to enable TLS 13 in your applications. And we encourage you to do this right away because later this year when TLS 1.3 is turned on by default, you don't risk problems with your service not being compatible. So test them right now to make sure everything will go smoothly when the switchover happens later this year.

Another element of security that's new is certificate transparency. You've probably heard cases where certificate authorities, either through malice or incompetence, issue rogue certificates to entities that they should not. The solution to this is something called certificate transparency logs. Every legitimate certificate authority now issues a public statement of every certificate it issues. And those are recorded in public logs for anybody to inspect. And this means that if a rogue certificate authority issues a bogus certificate, if it publishes it, they'll immediately get caught. And if they don't publish it, they'll be caught by the client.

This is the setup you're probably familiar with. The new entity here is the log. When a certificate authority issues a certificate to a server, it also records that with the log and the log gives the server a signed affidavit that its certificate has been publicly recorded. And then when the client connects, the server can give all that information to the client and the client can verify that not only is this a signed certificate, it is a publicly logged signed certificate. Now suppose we have a rogue certificate authority that doesn't publicly expose the rogue certificates it's issuing. The client will reject that because it doesn't have the affidavit to attest to it being recorded in a public log. Starting later this year, we will be enforcing this.

All newly issued TLS certificates must include the verification that they are publicly logged. And if they're not, then the client will reject it. Your apps don't need to make any changes, but if you have tailored certificates for your servers, make sure that your certificate authority is recording them in the public certificate transparency logs.

Now we have a bit of news for hardware developers. The Bonjour Conformance Test is a tool that lets you verify that your hardware devices implement Bonjour correctly. You need to run this test if you want to use the Bonjour trademark name and logo on your packaging. You need to run this test if you want to bundle the Bonjour for Windows installer with a Windows application. And if you want to use the AirPrint, AirPlay, CarPlay, HomeKit logos on your packaging, passing the Bonjour Conformance Test is a part of the logo licensing process because reliable Bonjour is an essential part of those products.

But more importantly, the value of running the Bonjour Conformance Test is it helps you improve the quality of your products and that makes them more reliable which makes your customers happy which makes your customers not return the product to the store because they can't make it work. And that's what your customers want.

That's what you want. And that's what we want. We want happy customers having a wonderful time with products that work reliably. Now I want to cover API choices. Thirty years ago we had BSD Sockets. And it was a great API 30 years ago. But 30 years ago we didn't have mobile computers in our pockets. We didn't have wireless networking. We didn't have IPv6.

We didn't have many computers with more than one network interface. If you had an Ethernet port on your computer, that was a fancy computer. Now 4 billion people around the world have a multi-homed IPv6 wireless battery-powered computing device that does power management and goes to sleep to save energy. The world has become a lot more complicated.

Many of you may be using third-party libraries which are built on that Sockets foundation. Many more of you may be using URLSession. And you may have assumed that URLSession is also just a wrap around Sockets. Well, not quite. URLSession is actually built using Apple's user space networking code network framework.

And starting now, in iOS 12, we are exposing that same API that URLSession uses so that your apps can directly use that for making TCP connections and other appropriate use cases. If you're doing things with URLs and HTTP GETs, URLSession is still your API of choice. But for the things URLSession doesn't cover, we now expose network framework so your apps can use that directly.

And if you're the developer of one of these third-party libraries, which are very popular that are built on BSD Sockets, we encourage you to look at the network framework APIs. Move your library over to these improved high-performance APIs, and give us feedback about how that goes for you.

So to summarize, we really strongly recommend here and now in 2018 that you avoid using BSD Sockets. Avoid using libraries that are nothing but wrappers around BSD Sockets. And if you are one of the authors of those libraries using these older APIs, look at switching over. Come and meet us in the labs this afternoon and tomorrow and give us your feedback about what it takes to move your libraries to new APIs. And with that, I would like to invite my colleagues Jiten to come up on stage and give you more details about URLSession.

Thank you, Stuart. Good morning everyone. My name is Jiten Mehta. And I'm an engineer on the CF network team. Today I'll be talking to you about some networking best practices for your apps. Networking is an essential part of every application. Each year, you guys do a great job of adding awesome features to your apps.

And today I'll be talking to you about some simple networking details, details that can help make your apps successful. Our agenda for today is going to cover four categories: reducing latency, maximizing throughput, increasing responsiveness, and making better use of system resources. Before that, let's quickly review URLSession, the API you've been using.

URLSession is the recommended high-level networking API available on all Apple platforms. URLSession has first-class support for HTTP/2 and HTTP/1.1. If your app does not use HTTP, we have support for URLSessionStreamTask, an API that allows you to make secure TCP connections to a server over which you can build your arbitrary protocol.

That's URLSession. Let's move on to our first agenda item: reducing latency. Let's suppose you and your friends go to a restaurant where the waiter walks up to you and you say, "Can I get a glass of water please?" The waiter say, "Sure," walks away, fetches you a glass of water.

Your friend then says, "Can I get a glass of water too?" The waiter says, "Sure," walks away, and fetches your friend a glass of water. Wouldn't it be faster if the waiter took everyone's order at the same time and reduce the number of round trips? The idea to reduce latency is simple. To reduce the number of back and forths when you fetch a resource. Let's see how your apps can do this.

First, let's look at some issues with HTTP/1.1. Your app wants to fetch a resource, you can create a URLSession task and call resume. URLSession will create a new connection for you, which involves DNS, TCP and TLS. Once the connection to the server is established, we will send out your request. We will then wait to get a response from the server. This is the network idle time when your app is not doing any kind of networking, waiting to get a response from the server.

Once we get a response, we will call your completion block or message your delegate indicating that the load has finished. Let's suppose in the middle of this load your app wants to fetch another resource from the same server. You can create another URLSession task called resume and URLSession will create a new connection to fetch this resource since it does not have an idle connection in its connection pool.

If your app wants to fetch yet another resource from the same server, you can create another URLSession task and call resume and we will create another connection to fetch the resource. In this example, I've shown you that we've created three different connections to fetch these resources from the same server. If you notice, we've spent a lot of time opening new connections. Let's see how this would look like if you used a single connection instead.

This is a single connection case. We saved a lot of time by not opening new connections, but there is another problem here. The request number two which is the green request has to wait until response number one is fully received. The same problem applies to request number three which is the orange request which has to wait until response number two is fully received. This problem is known as HTTP head-of-line blocking.

Consider moving to HTTP/2. HTTP/2 uses a single connection, and it also solves the HTTP head-of-line blocking problem. HTTP/2 multiplexes multiple streams over a single connection allowing you to receive parallel responses in an [inaudible] fashion. Let's analyze this example a little more to see how HTTP/2 performs better than HTTP/1.1.

Pay attention to the times when your app wants to fetch a resource and the time when the request is sent out. In the HTTP/1.1 case, there is a significant delay between the time when your app desires a resource and the time the request is sent out. HTTP/2 can significantly reduce this delay and allows us to send the request almost immediately when the app desires the resource.

Also pay attention to these gray boxes. If you recall, this is the network idle time when your app is not doing any networking, waiting to get a response from the server. HTTP/2 can significantly reduce this network idle time allowing you to better utilize the bandwidth and load the resources much faster.

We just discussed many benefits of using HTTP/2 over HTTP/1.1, but let's quickly summarize them. HTTP/2 solves the head-of-line blocking problem at the HTTP layer. And it also allows you to better utilize the bandwidth. If your apps use URLSession, you don't need to make any client-side changes. Simply enable HTTP/2 on your servers and you will see these benefits. By adopting HTTP/2, you can also get some server-side savings because devices running your apps will now make fewer connections to the servers. This year, we have something new in URLSession that is going to add to the advantages of HTTP/2.

Introducing HTTP/2 Connection Coalescing for URLSession. HTTP/2 Connection Coalescing is going to increase connection to use even more. Since your apps are not going to be opening new connections, they will become more responsive to your users. Starting with the [inaudible], HTTP/2 Connection Coalescing is going to be automatically done on for all your apps using URLSession. Now let's see how Connection Coalescing decides to reuse connections.

Let's suppose you have an app and that app wants to fetch a resource from menu.example.com. We open a connection with the server, and the server presents us with the certificate. If your app wants to fetch another resource from delivery.example.com, we open another connection and the server presents us with another certificate.

This is the old behavior where URLSession would create two connections to fetch these resources from the given host names. But if you look closely, the first certificate presented to us covers all the subdomains under example.com which means delivery.example.com is covered by this first certificate. Also notice that delivery.example.com, it results to the same IP address as the first connection.

At this point, it's safe for us to assume we're talking to the same endpoint and reuse the connection instead of opening a new one when we want to fetch the second resource. This saves us time by not opening a new connection and makes the load much faster. HTTP/2 [inaudible] HTTP/2 Connection Coalescing new in iOS 12 and macOS Mojave. Now let's see how using fewer URLSession objects can help reduce latency.

All the benefits of connections we use that we just discussed in the previous slides are applicable only if you use the same URLSession object to create your tasks. It's also important to know that every URLSession object has a connection pool and when you create multiple of these URLSession objects, you don't get any benefit of connection to use. It's also important to note that the URLSession objects are fairly expensive to create and have a non-trivial memory footprint. As we have in the past, we continue to advise you to use fewer URLSession objects.

Let's move on to our next topic for the day: maximizing throughput. Coming back to our restaurant example. The waiter checks up on you and you say, "Can I get an order of grilled chicken tossed in creamy tomato onion gravy made with a lot of butter?" Now that's a mouthful. Wouldn't it be easier if you just said, "Can I get butter chicken?" The idea to maximize throughput is the same where you reduce the number of bytes that you transmit when you want to fetch a resource. Let's see how your apps can do this.

Let's look at a couple of ways to reduce the request size. Pay attention to HTTP cookies. They are not free and have a non-trivial cost in storing and looking them up. Cookies are attached to all the requests that match the domain and path attribute. And it can quickly increase your request size.

Please use the domain and path attribute wisely to make sure cookies required by the servers are attached to your requests. Use of smaller cookies when possible, and delete these cookies when you no longer need them. Try to save some state on the server so you can reduce the number of client-side cookies. Also consider moving to HTTP/2 to get benefits of header compression. Let's talk a little more about compression.

HTTP compression, also known as content and coding, is simply compressing the data that is shuttled between the client and the server. This allows us to better utilize the bandwidth. The algorithms that URLSession supports and recommends are Gzip and Brotli. Gzip is widely supported and is relatively fast. Brotli support was introduced last year in iOS 11 and macOS High Sierra. Brotli is optimized for structured text and HTML. And it has the best compression ratio on short data. Please enable compression on your servers if you haven't done so already.

Let's move on to our next topic for the day: increasing responsiveness. Coming back to our restaurant example. Here you are here in San Jose for WWDC, and you decide to meet up with some old friends. You and your friends are sitting at the restaurant table. Your drinks are here, but you would like some more time to catch up with your friends before the food comes out.

You can simply tell the waiter, "Can you please bring out our food after some time? We are in no rush." The same concept can be applied to responsiveness where you mark your tasks with priority depending on the other tasks that you're doing. Let's see how your apps can benefit from this.

You might be familiar with these five QoS classes associated with dispatch queues and NSOperation objects. Data [inaudible] the CPU scheduling policy. URLSession is QoS-aware which means it will capture the QoS off the queue on which you call task.resume. And all the messages that it sends to your delegates will respect this QoS. Let's take an example. If your app wants to fetch some data which is not time critical, consider resuming that task on a queue which has background QoS to make sure this task does not contend for CPU with other higher priority work that your app might be doing.

Network service type is the property on the URLSession configuration object that allows you to classify your network traffic that helps the system prioritize the data leaving the device. This year, we have a new network service type, the responsiveData. ResponsiveData is slightly higher than the default type but should be used judiciously. An example where you might want to use responsiveData is if you have a shopping app and you are on the checkout page. You might want to mark your payment request with the responsiveData to make sure you get a good response from the server.

Traffic marked with the network service type property will maintain this tag across all the hops when on a Cisco Fast Lane network. For more information on this API, please view the WWDC session from the year 2016. Last year, we introduced the URLSession Adaptable Connectivity API waitsForConnectivity. waitsForConnectivity will simply wait instead of failing the load when your task does not have connectivity.

In the past, you've been using STNeworkReachability to do a preflight check before you send out your request. But as Stuart pointed out a few slides ago, there is a race condition where the system might tell you that you have connectivity to a server but by the time you create and send your request, you've lost your chance and you're no longer connected to the server.

We recommend using waitsForConnectivity which will simply send out your request as soon as a connection to the server is available. Optionally, you can implement the taskIsWaitigForConnectivity delegate method which gets called when your task does not have connectivity. This can be helpful to present the user with a different flow or an offline UI for better user experience.

For more information on this API, please view the WWDC session from last year where this API was introduced. Now let's move on to our last topic for the day: making better use of system resources. Coming back to our restaurant example. You like the food at this place so much that you decide to come here for dinner the next day.

The restaurant has a delivery service where you can place your order today and they will deliver the food to your house the next day. This not only saves you the time and effort to go and pick up your food but it also helps the restaurant prioritize their work based on your deadline. Let's see how your apps can make better use of system resources to be more efficient.

Background sessions have upload and download tasks. These tasks use system intelligence to decide when to start and when to stop a download based on various factors like battery, CPU, Wi-Fi, etcetera. If your app wants to fetch a large file, consider using background sessions. These tasks run out of process which means your download will continue even when your app is in a suspended state. For more information on background sessions, please view the WWDC session from the year 2014.

Caching is a great way of reducing latency but it's important to note that caching might result in disk IO. In the real world, we've seen some apps write several gigabytes of data to disk each day which can cause severe flash storage degradation. Please don't cache unique content. Let's take an example. Let's suppose you have an app, a dating app, and you are responsible for the networking code of the app.

This app loads user profiles with high-resolution images. It might be wasteful to cache these high-resolution images because the user might swipe left, move on to the next profile, which means that the images that you just cached are probably not going to be requested again. Please consider making client-side changes by adopting the willChacheResponse delegate method to decide what resources should be cached. If you own the servers, please consider using cache control headers to decide what resources should be cacheable.

Let's quickly go over some of the key points that we discussed today. Number one, order all your food at the same time when you go to a restaurant. I'm just kidding. Move to HTTP/2 today to get wins like header compression, connection coalescing and no head-of-line blocking. Use fewer URLSession objects to reduce latency by reusing connections. This also reduces the memory footprint so it's better use of system resources. Reduce the request size to maximize throughput.

Pay attention to QoS to increase the responsiveness of your apps. And finally use background sessions when you can to make better use of system resources. For more information on this session, please visit this website. Now we'll have a short break. And after the break, we'll introduce you to network framework, a modern alternative to Sockets. I would love to see you all at the networking labs which are going to be held today and tomorrow. Thank you all for being here. And I hope everyone has a great rest of the conference.