gRPC<\/h2>\n
Lou Montulli cr\u00e9ateur du cookie et dev sur Lynx. (1994, puis RFC en 1997 et 2000)\n-> au d\u00e9part : web compl\u00e8tement stateless et le cookie a \u00e9t\u00e9 cr\u00e9\u00e9 pour pouvoir impl\u00e9menter un \u00e9tat c\u00f4t\u00e9 client\n-> Brev\u00eat Netscape rachet\u00e9 par Fb …\n-> les bases du cookie :\n=> client request serveur -> Server Set-Cookie : “42” -> Nav dans jarre -> client request 2 Cookie : “42”\n=> cookie expir\u00e9 \u00e0 la fermeture de session par d\u00e9faut ou \u00e0 date pr\u00e9cise (Expires) ou en dur\u00e9 (Max-Age en seconde)\n=> supression d’un cokie : expires avec date dans le pass\u00e9 ou max-age 0\n=> d\u00e9finit sur un domain (ou sans) : domaine augmente la port\u00e9e du cookie par tous les hotes qui se terminent par la valeur (sans : egualit\u00e9 stricte)\n=> pas possible de mettre un cookie sur un top level domain … pb des tld en deux partie (ex co.uk) r\u00e9solu depuis une RFC de 2011 qui d\u00e9finit une liste\nde “suffixe publique” utilis\u00e9 par la pluspart des navigateurs (sauf eddge)\n=> pas possible de mettre Domain=localhost\n=> path : permet de limiter l’envoit des cookie sur certaines URL (commencent par le path)\n=> un cookie d\u00e9pos\u00e9 en HTTPS sera accessible en HTTP sauf si d\u00e9pos\u00e9 avec l’attribut secure (envoit uniquement en HTTPS)\n=> un cookie d\u00e9pos\u00e9 en HTTP pourra \u00eatre secure et envoy\u00e9 en HTTPS dans une requ\u00eates successive => draft pour ne suporter le secure qu’en https\n=> un serveur ne re\u00e7oit que le cookie et ne sais donc pas s’il est secure : draft pour utilisation d’un prefix Secure\nni s’il est sur un domain ou un path pr\u00e9cise : prefix <\/strong>Host (RFC draft 2017)\n=> attention : le port n’est pas pris en compte pour diff\u00e9rencier les cookie (n’ob\u00e9it pas \u00e0 la same origin policy)\n-> Si on est sur une page example.com et qu’on app\u00e8lle une URL en cookies.rocks … les cookies de cookies.rocks vont \u00eatre envoy\u00e9 => CSRF !\n=> nouvel attribut SameSite permet d’\u00e9viter le risque de CSRF en disant au nav de ne pas envoyer de cookie quand on est dans une page diff\u00e9rente\n-> les cookie sont accessible en Javascript via document.cookie => faille XSS possible\n=> attribut HttpOnly permet d’\u00e9viter que le cookie soit lu via JS et donc le XSS\n-> les cookies permettent de tracer les utilisateurs via une simple image sur une page diff\u00e9rente car dans la requ\u00eates il y a le referer …\n=> technique de traking qui d\u00e9tourne l’usage primaire …<\/p>\n -> Service Mesh : ajoute plein de services \u00e0 Kubernetes : zipkin, grafana, service graph, prometheus\n-> ajout automatique depuis Kubernetes via des composant “Envoy” int\u00e9gr\u00e9 automatiquement dans les pod\n-> service graph : graphe des services utilis\u00e9 par une requ\u00eate avec le nb req\/s\n-> int\u00e9gration prometheus \/ grafana\n-> int\u00e9gration zipkin : tracing des requ\u00eates dans tous les services … sans modification de l’apps existante!\n-> d\u00e9ployement controll\u00e9 : canary deployement : d\u00e9ployer uniquement pour une partie des utilisateur et monitor\u00e9 ce canary\n=> configuration \u00e0 faire dans Istio pour un canary deployement via un RouteRule qui d\u00e9finit des r\u00e8gles de routage (destination, request header, …)\n-> traffic mirroring : possibilit\u00e9 de copier le traffic d’un service \u00e0 l’autre : ex envoyer tous en double sur le service 1 et 2 pour valider ‘en live’ une nouvelle version\n-> Pas encore en version finale … des bugs existent … surtout que c’est un ensemble de composants OSS externe …\n-> Blue\/Green deployement : ppossibilit\u00e9 de router une fraction des utilisateurs vers le nouveau service\n-> Dev par Google\n-> Solution totalement modulable<\/p>\n <\/p>","protected":false},"excerpt":{"rendered":" gRPC Rappel r\u00e9seau, internet Probl\u00e9matique du format de donn\u00e9e dans les systeme distribu\u00e9 => modification difficile Historique des protocoles RCP : CORBA, RMI, EJB, SOAP, REST -> 2008 Protocol Buffers : s\u00e9rialization (pr\u00e9mice du RCP chez Google : open sourcing partiel) -> 2009 Thrift (Fb) -> 2015 gRPC (bas\u00e9 sur Protocol Buffers) gRPC : syst\u00e8me de RPC avec Protocol Buffers comme s\u00e9rialization et bas\u00e9 sur des Interface Description Language et incub\u00e9 depuis peu dans la Cloud Native Fondation IDL :…Istio:<\/h2>\n