À partir du 1 janvier 2017, toutes les applications iOS soumises à Apple devront utiliser des connexions sécurisées HTTPS pour être validées. Pour les développeurs, cela reviendra à prendre en charge App Transport Security, une fonction introduite dans iOS 9 et El Capitan qui était jusque-là recommandée mais pas obligatoire.
IPv6
Stuart Cheshire, ingénieur émérite d'Apple, a annoncé d'autres nouveautés réseau durant une session de la WWDC 2016 résumée par Ars Technica. Le protocole IPv6, lancé symboliquement il y a quatre ans dans le monde entier, représente aujourd'hui jusqu'à 70 % des connexions du site apple.com avec certains opérateurs, comme Verizon. 40 % des connexions provenant de la Belgique, en pointe sur la technologie, sont en IPv6.
Non seulement l'IPv6 résout le problème de la pénurie d'adresses de l'IPv4, mais en plus il accélère la navigation. Le chargement des pages web mobiles de LinkedIn est 10 à 40 % plus rapide, et une requête HTTP sur Facebook 15 à 30 % plus rapide.
iOS 9 et El Capitan ont commencé à favoriser l'IPv6 au détriment de l'IPv4. Comme tous les serveurs ne sont pas passés à l'IPv6, un mécanisme permet de traduire les adresses en IPv4.
Or, ce mécanisme ne fonctionne pas quand la connexion se fait directement à l'adresse IPv4 (par exemple 17.172.224.47), sans interroger le système de nom de domaine (http://www.apple.com). Apple modifie ce comportement dans plusieurs API d'iOS 10 et Sierra en ajoutant la prise en charge des adresses IPv4 littérales. Cela étant, la consigne est toujours de préférer l'IPv6 quand c'est possible.
Explicit Congestion Notification (ECN)
Promise dans iOS 9 et OS X 10.11, la fonction Explicit Congestion Notification (ECN) arrive finalement dans leur successeur. ECN est une réponse au problème de congestion du réseau. L'ingénieur Stéphane Bortzmeyer explique sur son blog la problématique :
La congestion, [c'est] le fait qu'il y ait plus de paquets IP qui veulent passer par les tuyaux que de capacité pour les faire passer. La réponse classique d'IP à la congestion est de laisser tomber certains paquets, les protocoles de plus haut niveau étant alors censés ralentir en réponse à ces pertes. [...] Mais cela fait perdre des données, juste pour envoyer une indication. D'où l'idée de prévenir avant que la congestion ne soit réellement installée, en modifiant deux bits de l'en-tête IP, pour indiquer que le routeur a du mal à suivre. Les machines terminales, si elles gèrent ECN, vont alors ralentir leur débit de manière plus efficace que si elles avaient attendu en vain un paquet.
ECN existe en fait depuis le début des années 2000, mais s'il n'a pas été adopté avant par Apple (et fait un faux départ dans iOS 9 et El Capitan), c'est parce qu'il n'était pas correctement géré jusqu'à présent par certains équipements et acteurs. L'année dernière, un opérateur allemand a par exemple signalé temporairement tous les paquets comme congestionnés, ce qui a dégradé les connexions.
Mais l'internet est maintenant prêt pour ECN, assure Stuart Cheshire. 70 % des sites les plus visités gèrent ECN, et même 83 % pour ceux qui sont en IPv6. Apple a d'ailleurs activé partiellement ECN dans iOS 9.3 et OS X 10.11.5 : une session réseau sur 20 utilise la fonction. Dans les bêtas de macOS Sierra et iOS 10, ECN est continuellement actif en Wi-Fi ainsi que sur les réseaux cellulaires de certains opérateurs.
Assistance Wi-Fi
L'Assistance Wi-Fi d'iOS 9 est une bonne idée qui a été mal accueillie. Cette fonction activée par défaut qui privilégie le réseau cellulaire quand la connexion Wi-Fi est faible a rapidement été critiquée pour son hypothétique consommation excessive de data. La faute incombait en partie à Apple qui ne donnait pas d'informations à ce sujet. À partir d'iOS 9.3, on a pu se rendre compte que l'Assistance Wi-Fi consommait en fait très peu de données.
Stuart Cheshire a défendu l'intérêt de cette fonction et annoncé un changement dans la gestion du passage d'un type de connexion à un autre. Prenons le cas du chargement automatique de photos de Dropbox qui s'active uniquement en Wi-Fi si on le souhaite.
Actuellement, l'application commence par interroger iOS pour savoir si l'iPhone est connecté en Wi-Fi ou en 4G, puis débute le transfert s'il est en Wi-Fi. Or, le type de connexion peut changer d'une seconde à l'autre.
La nouvelle méthode renverse la logique pour une meilleure réactivité : l'application va d'abord essayer de transférer les photos, et si le système lui indique que l'iPhone est en 4G, elle va stopper l'opération. L'application peut alors demander à l'utilisateur s'il veut réaliser le transfert en 4G ou tout simplement attendre le retour du Wi-Fi.
