diff --git a/ko/part7.md b/ko/part7.md
index c7e4b06..bf3b103 100644
--- a/ko/part7.md
+++ b/ko/part7.md
@@ -1,5 +1,31 @@
-#7. 연장선
+# 7. 확장들
 
-(번역되지 않은)
+HTTP/2 프로토콜은 수신자가 알 수 없는 모든 프레임(알려지지 않은 프레임 유형을 가진 것들)을 읽고 무시해야 한다고 규정합니다. 두 당사자는 홉 단위로 새로운 프레임 유형의 사용을 합의할 수 있지만, 이러한 프레임들은 상태 변경이 허용 되지 않으며 흐름 제어되지 않습니다.
 
-[영어](../en/part7.md)
+HTTP/2가 확장을 허용해야 하는지에 대한 주제는 프로토콜 개발 동안 길게 논의되었으며, 찬성과 반대 의견이 오갔습니다. draft-12 이후 마지막으로 의견의 흐름이 한 번 더 바뀌었고 결국 확장이 허용되었습니다.
+
+확장 기능은 실제 프로토콜의 일부가 아니지만 핵심 프로토콜 사양 외부에 문서화될 예정입니다. 이미 프로토콜에 포함하기 위해 논의된 두 가지 프레임 유형이 있는데, 아마도 확장으로 보내지는 첫 번째 프레임이 될 것입니다. 여기서는 인기있고, "네이티브" 프레임처럼 사용되던 두 가지 프레임에 대해 설명하겠습니다:
+
+## 7.1. 대체 서비스
+
+HTTP/2의 채택으로 TCP 연결이 훨씬 더 길어지고 HTTP 1.x 연결보다 훨씬 더 오래 유지될 것이라고 예상하는 이유가 있습니다. 클라이언트는 각 호스트/사이트에 대해 단일 연결로 원하는 많은 작업을 수행할 수 있으며, 이 연결은 상당한 시간 동안 열릴 수 있습니다.
+
+이는 HTTP 로드 밸런서의 작동 방식에 영향을 미칠 것이며, 사이트가 클라이언트에게 다른 호스트에 연결하도록 제안하고 싶어하는 상황이 발생할 수 있습니다. 이는 성능상의 이유이거나 사이트가 유지보수를 위해 중단되는 경우 등일 수 있습니다.
+
+서버는 [Alt-Svc 헤더](https://tools.ietf.org/html/rfc7838) (또는 HTTP/2의 ALTSVC 프레임)를 보내 클라이언트에 대체 서비스를 알립니다: 동일한 콘텐츠에 대해 다른 서비스, 호스트 및 포트 번호를 사용하는 다른 경로입니다.
+
+그런 다음 클라이언트는 그 서비스에 비동기적으로 연결을 시도하고 새 연결이 성공할 경우에만 대체 서비스를 사용해야 합니다.
+
+### 7.1.1. Opportunistic TLS
+
+Alt-Svc 헤더는 http:// 를 통해 콘텐츠를 제공하는 서버가 동일한 콘텐츠가 TLS 연결을 통해서도 사용할 수 있다는 정보를 클라이언트에게 알릴 수 있습니다.
+
+이것은 다소 논란이 있는 기능입니다. 이러한 연결은 인증되지 않은 TLS를 수행하고 UI에서 “안전하다”고 광고되지 않으며, 어떤 자물쇠도 사용되지 않고, 사실 이것이 단순한 구식 HTTP가 아니라는 것을 사용자에게 알릴 방법이 없습니다. 그러나 이것은 여전히 기회주의적 TLS이며, 일부 사람들은 이 개념에 매우 강하게 반대합니다.
+
+## 7.2. Blocked
+
+이 유형의 프레임은 HTTP/2 당사자가 데이터를 보내고자 하지만 흐름 제어가 데이터 전송을 금지할 때 정확히 한 번 보내기 위해 의도된 것입니다. 이 아이디어는 당신의 구현이 이 프레임을 받았을 때, 당신이 뭔가를 잘못 처리했거나/또는 완벽하지 않은 전송 속도를 얻고 있다는 것을 알 수 있습니다.
+
+draft-12에서 이 프레임이 확장으로 이동하기 전의 인용:
+
+> "BLOCKED 프레임은 실험을 용이하게 하기 위해 이 초안 버전에 포함되어 있습니다. 실험 결과가 긍정적인 피드백을 제공하지 않는 경우, 제거될 수 있습니다."
diff --git a/ko/part8.md b/ko/part8.md
index 3846350..a7c06a8 100644
--- a/ko/part8.md
+++ b/ko/part8.md
@@ -1,5 +1,131 @@
-#8. http2 세계
+# 8. http2 세상
 
-(번역되지 않은)
+그렇다면 http2가 도입되면 어떤 모습일까요? 도입될까요?
 
-[영어](../en/part8.md)
+## 8.1. 일반인에게 http2가 미치는 영향
+
+http2는 아직 널리 배포되거나 사용되지 않았습니다. 결과가 어떻게 될지 확실하게 말할 수 없습니다. 우리는 SPDY가 어떻게 사용 되는지를 보았고, 그 사례와 과거 및 현재의 실험을 바탕으로 일부 예측과 계산을 할 수 있습니다.
+
+http2는 필요한 네트워크 왕복 횟수를 줄이고, 멀티플렉싱과 원하지 않는 스트림의 빠른 폐기를 통해 헤드 오브 라인 블로킹 문제를 완전히 피합니다.
+
+이 프로토콜은 오늘날 가장 많이 샤딩된 사이트들조차 넘어서는 많은 양의 병렬 스트림을 허용합니다.
+
+스트림에 적절히 우선순위를 부여하면, 클라이언트가 중요한 데이터를 덜 중요한 데이터보다 먼저 받을 가능성이 훨씬 높아집니다. 이 모든 것을 종합하면, 이것이 페이지 로드 속도를 높이고 웹 사이트의 반응성을 향상시켜 더 나은 웹 경험을 제공할 가능성이 매우 높습니다.
+
+얼마나 더 빨리 개선될지는 아직 말할 수 없습니다. 첫째, 이 기술은 아직 초기 단계이며, 클라이언트와 서버가 이 새로운 프로토콜이 제공하는 모든 기능을 실제로 활용하기 위해 구현의 조정을 시작하지도 않았습니다.
+
+## 8.2. http2가 웹 개발에 얼마나 영향을 미칠까요?
+
+수 년 동안 웹 개발자들과 웹 개발 환경은 HTTP 1.1의 문제를 우회하기 위해 여러 가지 도구와 기술을 개발했습니다. 이 문서 초반부에서 http2를 정당화하기 위해 그 중 일부를 소개했습니다.
+
+현재 개발자가 아무 생각 없이 기본값으로 사용하는 많은 도구나 해결 방법은 아마도 http2 성능을 저하시키거나 적어도 http2의 새로운 능력을 제대로 활용하지 못할 것입니다. 스프라이팅과 인라이닝은 대부분 http2에서 수행하지 않는 것이 좋습니다. 샤딩은 아마도 더 적은 수의 연결을 사용함으로써 이점을 얻을 수 있기 때문에 http2에 해로울 것입니다.
+
+물론 여기서 문제는 웹 사이트와 웹 개발자가 적어도 단기적으로는 HTTP1.1과 http2 클라이언트를 모두 사용하게 될 세상을 위해 개발 및 배포해야 하며, 두 가지 프론트엔드를 제공하지 않고 모든 사용자에게 최고의 성능을 제공하는 것이 어려울 수 있다는 점입니다.
+
+이러한 이유로, http2의 전체 잠재력이 실현되기까지는 어느 정도 시간이 걸릴 것이라고 생각합니다.
+
+## 8.3. http2 구현
+
+이와 같은 문서에서 구체적인 구현을 문서화하는 것은 완전히 헛된 일이며 매우 빠르게 시대에 뒤떨어질 것 입니다. 대신에, 더 넓은 관점에서 상황을 설명하고 독자들을 http2 웹사이트의 [구현 목록](https://github.com/http2/http2-spec/wiki/Implementations)으로 안내할 것입니다.
+
+구현의 수는 초기에 많았으며 http2 작업이 진행됨에 따라 시간이 지남에 따라 증가했습니다. 이 글을 쓰는 시점에서 40개 이상의 구현이 나열되어 있으며, 대부분은 최종 버전을 구현합니다.
+
+### 8.3.1 브라우저
+
+Firefox는 가장 최신의 초안을 사용하는 브라우저 중 하나입니다. Twitter는 http2를 통해 서비스를 제공하고 있습니다. Google은 2014년 4월부터 몇 개의 테스트 서버에서 서비스를 운영하기 시작했으며, 2014년 5월부터는 Chrome의 개발 버전에서 http2 지원을 제공합니다. Microsoft는 다음 Internet Explorer 버전에서 http2 지원을 보여주는 기술 미리보기를 선보였습니다. Safari(iOS 9 및 Mac OS X El Capitan에서)와 Opera도 http2를 지원할 것이라고 밝혔습니다.
+
+### 8.3.2 서버
+
+이미 많은 서버 구현이 있습니다.
+
+인기 있는 Nginx 서버는 2015년 9월 22일에 출시된 [1.9.5](https://www.nginx.com/blog/nginx-1-9-5/) 버전부터 http2 지원을 제공합니다(이 버전에서는 SPDY 모듈을 대체하여 같은 서버 인스턴스에서 둘 다 실행할 수 없습니다).
+
+Apache의 httpd 서버는 2015년 10월 9일에 출시된 2.4.17 버전부터 http2 모듈 [mod_http2](https://httpd.apache.org/docs/2.4/mod/mod_http2.html)를 가지고 있습니다.
+
+[H2O](https://h2o.examp1e.net/), [Apache Traffic
+Server](https://trafficserver.apache.org/), [nghttp2](https://nghttp2.org/),
+[Caddy](https://caddyserver.com/) 및
+[LiteSpeed](https://www.litespeedtech.com/products/litespeed-web-server/overview)
+는 모두 http2 지원 서버를 출시했습니다.
+
+### 8.3.3 기타
+
+curl과 libcurl은 여러 가지 TLS 라이브러리 중 하나를 사용하는 TLS 기반뿐만 아니라 안전하지 않은 http2도 지원합니다.
+
+Wireshark은 http2를 지원합니다. http2 네트워크 트래픽을 분석하는 데 완벽한 도구입니다.
+
+## 8.4. http2에 대한 일반적인 비판
+
+이 프로토콜을 개발하는 동안 논쟁은 계속되어 왔으며, 물론 이 프로토콜이 완전히 잘못되었다고 생각하는 사람들도 어느 정도 존재합니다. 몇 가지 일반적인 불만 사항을 언급하고 이에 대한 반론을 언급하고 싶습니다:
+
+
+### 8.4.1. “프로토콜이 구글에 의해 설계되거나 만들어졌다”
+
+또한 이로 인해 전 세계가 구글에 더욱 의존하거나 통제받는다는 의미의 주장도 있습니다. 이는 사실이 아닙니다. 이 프로토콜은 30년 이상 프로토콜이 개발되어 온 것과 같은 방식으로 IETF 내에서 개발되었습니다. 그러나 우리 모두는 새로운 프로토콜을 이런 방식으로 배포할 수 있다는 것을 증명했을 뿐만 아니라 어떤 이득을 얻을 수 있는지를 보여주는 수치를 제공한 Google의 SPDY 프로토콜에 대한 대단한 작업을 존중하고 인정합니다.
+
+Google은 2016년에 Chrome에서 SPDY와 NPN에 대한 지원을 중단한다고 공개적으로 [발표](https://blog.chromium.org/2015/02/hello-http2-goodbye-spdy.html)하고 대신 서버를 HTTP/2로 마이그레이션할 것을 촉구했습니다. 그리고 2016년 2월, 마침내 Chrome 51에서 SPDY와 NPN이 제거될 것이라고 [발표](https://blog.chromium.org/2016/02/transitioning-from-spdy-to-http2.html)했습니다. Chrome 51부터는 SPDY와 NPN을 지원하지 않고 출시되었습니다.
+
+
+### 8.4.2. “프로토콜은 브라우저에만 유용하다”
+
+이것은 어느 정도 사실입니다. http2 개발의 주된 동기 중 하나는 HTTP 파이프라이닝을 고치는 것이었습니다. 만약 당신의 사용 사례가 원래 파이프라이닝을 필요로 하지 않았다면, http2는 많은 도움이 되지 않을 것입니다. 이 프로토콜의 유일한 개선 사항은 아니지만, 큰 지분을 차지합니다.
+
+서비스가 단일 연결 위의 멀티플렉스 스트림의 전력과 능력을 깨닫기 시작하면, 나는 우리가 http2의 더 많은 애플리케이션 사용을 보게 될 것이라고 의심합니다.
+
+작은 REST API와 HTTP 1.x의 더 단순한 프로그래매틱 사용은 http2로의 전환에서 큰 이점을 발견하지 못할 수도 있습니다. 하지만 대부분의 사용자에게는 http2가 거의 불이익이 없어야 합니다.
+
+### 8.4.3. “프로토콜은 큰 사이트에만 유용하다”
+
+전혀 그렇지 않습니다. 멀티플렉싱 기능은 높은 대기 시간 연결을 제공하는 작은 사이트들의 경험을 크게 개선할 수 있습니다. 큰 사이트는 이미 매우 빠르고 분산되어 있으며 사용자에게 짧은 왕복 시간을 제공합니다.
+
+### 8.4.4. “TLS 사용은 더 느리다”
+
+이는 어느 정도 사실일 수 있습니다. TLS 핸드셰이크는 약간의 오버헤드를 추가하지만, TLS에 필요한 라운드 트립을 더 줄이기 위한 기존 및 지속적인 노력이 진행 중입니다. 일반 텍스트 대신 TLS를 유선으로 수행할 때 발생하는 오버헤드는 크지 않으며, 비보안 프로토콜과 동일한 트래픽 패턴에서 더 많은 CPU와 전력을 소비하게 됩니다. 얼마나 많은 영향을 미칠지는 의견과 측정의 대상입니다. 예시를 위해 [istlsfastyet.com](https://istlsfastyet.com/)을 정보의 한가지 출처로 참고하세요.
+
+통신 및 기타 네트워크 운영자들은 예를 들어 ATIS Open Web Alliance에서 캐싱, 압축 및 기타 기술을 제공하기 위해 비암호화된 트래픽이 필요하다고 말합니다. 이것은 위성, 비행기 및 유사한 환경에서 빠른 웹 경험을 제공하는 데 필요합니다. http2는 TLS 사용을 의무화하지 않으므로 우리는 이 용어들을 혼동해서는 안 됩니다.
+
+많은 인터넷 사용자들이 TLS의 보다 널리 사용될 것을 선호하며, 우리는 사용자의 개인 정보를 보호하는 데 도움을 주어야 합니다.
+
+또한 실험에 따르면 포트 80을 넘어가고 HTTP처럼 보인다면 HTTP 1.1로 간주해 간섭하는 미들박스가 너무 많기 때문에 포트 80을 통해 새로운 일반 텍스트 프로토콜을 구현할 때보다 TLS를 사용하면 성공률이 더 높다는 사실이 밝혀졌습니다.
+
+마지막으로, 단일 연결을 통한 http2의 다중 스트림 덕분에 일반적인 브라우저 사용 사례에서는 여전히 TLS 핸드셰이크를 훨씬 적게 수행하여 HTTP 1.1을 사용할 때보다 더 빠른 성능을 발휘할 수 있습니다.
+
+마지막으로, http2의 단일 연결 위의 멀티플렉스 스트림 덕분에, 일반적인 브라우저 사용 사례에서는 여전히 HTTP 1.1을 사용하는 HTTPS보다 훨씬 적은 TLS 핸드셰이크를 수행하므로 더 빠를 수 있습니다.
+
+### 8.4.5. “ASCII가 아니라는 것은 거래 파기자이다”
+
+맞아요, 우리는 프로토콜을 명확하게 볼 수 있기를 좋아합니다. 왜냐하면 그것은 디버깅과 추적을 쉽게 만들기 때문입니다. 하지만 텍스트 기반 프로토콜은 오류가 발생하기 쉬우며, 훨씬 더 많은 파싱과 파싱 문제를 유발합니다.
+
+만약 이진 프로토콜을 처리할 수 없다면, HTTP 1.x에서 매우 오랫동안 존재하고 사용된 TLS와 압축을 처리할 수 없었을 것입니다.
+
+### 8.4.6. “HTTP/1.1보다 빠르지 않다”
+
+물론 더 빠르다는 것이 무엇을 의미하는지 측정하는 방법에 대한 논쟁과 토론의 대상이지만, 이미 SPDY 시절에 브라우저 페이지 로드가 더 빠르다는 것을 증명하는 많은 테스트가 수행되었으며(워싱턴 대학의 사람들에 의해 ["SPDY가 얼마나 빠른가?"](https://www.usenix.org/system/files/conference/nsdi14/nsdi14-paper-wang_xiao_sophia.pdf) 및 Hervé Servy의  ["SPDY가 활성화된 웹 서버의 성능 평가"](https://www.neotys.com/blog/performance-of-spdy-enabled-web-servers) 등) 이러한 실험은 http2에서도 반복되고 있습니다. 더 많은 테스트와 실험이 발표되기를 기대하고 있습니다. [httpwatch.com에 의한 기본 첫 번째 테스트](https://blog.httpwatch.com/2015/01/16/a-simple-performance-comparison-of-https-spdy-and-http2)는 http2가 약속을 지키고 있음을 시사하고 있습니다.
+
+### 8.4.7. “레이어 위반을 한다”
+
+진지하게, 그게 당신의 주장인가요? 레이어는 전 세계 종교의 거룩하고 불가침의 기둥이 아니며, 만약 우리가 http2를 만들면서 몇 가지 회색 지역으로 넘어갔다면, 그것은 주어진 제약 내에서 좋고 효과적인 프로토콜을 만들기 위한 것이었습니다.
+
+### 8.4.8. “HTTP/1.1의 여러 단점을 해결하지 않는다”
+
+사실입니다. HTTP/1.1 패러다임을 유지한다는 구체적인 목표를 위해 흔히 문제시되는 쿠키, 인증 헤더 등을 포함하는 공통 헤더와 같은 몇 가지 오래된 HTTP 기능을 남겨야 했습니다. 하지만 이러한 패러다임을 유지함으로써 얻을 수 있는 장점은 기본적인 부분을 완전히 교체하거나 다시 작성해야 하는 상상할 수 없을 정도의 업그레이드 작업 없이 배포할 수 있는 프로토콜을 갖게 되었다는 점입니다. Http2는 기본적으로 새로운 프레임워크 계층에 불과합니다.
+
+## 8.5. http2가 널리 배포될까요?
+
+(이 섹션은 2015년에 작성되었으며, 당시의 상황을 보여줍니다. 이후 상황은 크게 변화했습니다.)
+
+확실히 말하기에는 너무 이르지만 추측하고 추정할 수는 있으며 여기서는 그렇게 하겠습니다.
+
+부정적인 사람들은 "IPv6가 얼마나 잘 되고 있는지 보라"고 말할 것입니다. 이것은 새로운 프로토콜이 수십 년 동안 널리 배포되기 시작하는 데 걸린 한 예입니다. 하지만 http2는 IPv6와는 다릅니다. 이 프로토콜은 TCP 위의 프로토콜로, 일반적인 HTTP 업데이트 메커니즘과 포트 번호 및 TLS 등을 사용합니다. 대부분의 라우터나 방화벽을 변경할 필요가 없습니다.
+
+Google은 SPDY 작업을 통해 이와 같은 새로운 프로토콜이 상당히 짧은 시간 내에 여러 구현을 통해 브라우저와 서비스에서 배포되고 사용될 수 있음을 전 세계에 증명했습니다. 현재 인터넷에서 SPDY를 제공하는 서버의 수는 1%대에 불과하지만, 이러한 서버가 처리하는 데이터의 양은 훨씬 더 많습니다. 오늘날 가장 인기 있는 웹사이트 중 일부는 SPDY를 제공합니다. 
+
+SPDY와 동일한 기본 패러다임에 기반한 http2는 IETF 프로토콜이기 때문에 더 많이 배포될 가능성이 높다고 생각합니다. SPDY 배포는 항상 "구글 프로토콜"이라는 오명 때문에 약간 주춤했습니다.
+
+이번 출시에는 여러 대형 브라우저의 지원이 있었습니다. 파이어폭스, 크롬, 사파리, 인터넷 익스플로러, 오페라 대표들은 http2 지원 브라우저를 출시할 것이라고 밝혔으며, 실제로 구현된 모습을 보여주었습니다.
+
+구글, 트위터, 페이스북 등 몇몇 대형 서버 운영자가 곧 http2를 제공할 것으로 보이며, 아파치 HTTP 서버와 nginx 등 인기 있는 서버 구현에도 곧 http2 지원이 추가될 것으로 기대됩니다. H2o는 http2를 지원하는 놀랍도록 빠른 새로운 HTTP 서버로 잠재력을 보여주고 있습니다.
+
+HAProxy, Squid, Varnish 등 대형 프록시 공급업체 중 일부가 http2를 지원하겠다는 의사를 표명했습니다.
+
+2015년 내내 http2 트래픽의 양은 계속 증가하고 있습니다. 9월 초에 Firefox 40의 사용량의 전체 HTTP 트래픽 중 13%, 전체 HTTPS 트래픽 중 27%가 http2 트래픽이였습니다. Google은 수신 요청의 약 18%를 HTTP/2로 보고 있습니다. Google은 다른 새로운 프로토콜 실험(12.1의 QUIC 참조)도 진행 중이므로 HTTP2 사용량 수준은 이보다 낮을 수 있다는 점에 유의해야 합니다.
\ No newline at end of file