컴퓨터 네트워크 (9), HTTPS and SIP

HTTPS and SIP

 

- HTTPS는 웹브라우저와 웹서버의 통신을 지배하고 있다.

- transport layer로 얘기를 하기도 한다.

- 로그인 -> 세션의 채팅방 -> 음성통화나 화상통화 가능. 이러한 음성 전화나 화상통신은 IP based인 SIP을 사용한다. instance messanger, 줌 등의 핵심 기술이다.

 

Textbook of HTTPS Chapter

HTTP: The Definitive Guide

- 프로그래밍 랭귀지에 HTTP가 들어갈만큼 일반화된 기술이다.

 

1. HTTP 1.x

1) Web Client and Servers

- 웹브라우저를 띄우면 이는 웹 클라이언트가 되고 HTTP를 사용해 웹브라우저가 동작한다.

- 정보를 요청하는 자는 웹 클라이언트, 정보를 제공하는 자는 웹 서버라고 한다.

- HTTP를 사용해 클라이언트가 정보를 요청하고, 정보를 제공한다.

- 요청할 때는 루트 디렉토리 하위에 위치한 index.html을 요청한다.

- reponse할 때는 문자 길이 등과 함께 포멧을 전달한다.

- 인터넷을 물리학자들이 만든 연구결과를 주고받기 위해 만들어졌다. 이때 문자, 데이터, 그림 등과 함께 문서를 보여주고자 했다. 

 

2) Resources

- 웹에서의 리소스는 주로 파일을 의미한다. 운영에서의 리소스는 CPU, 디스크, 메모리 등이 될 수 있다.

 

(1) Static contents

- HTTP 리쿼스트가 서버에 도착하는 시점에 파일이 존재하는 경우

- 이미 존재하는 파일은 바뀌지 않는다.

ex) MS file, Image file, 동영상 등등

cf) 넷플릭스에서의 동영상을 보는 것

 

(2) Dynamic contents

- HTTP 리쿼스트가 서버에 도착하는 시점 이후에 파일을 만드는 경우

- 지금 상황의 시점에 기반해 파일이나 데이터를 만드는 것이다. 따라서 프로그램이 데이터를 보고 파일을 그때그때 만들어서 response를 돌려준다.

ex) Live Image(접속한 사람에 맞춰 만드는 이미지), Trade Stocks 등등

 

(3) MIME

- HTTP response가 클라이언트에게 갈 때 그림이 가면서 그림과 관련된 정보도 전달된다. 이는 바이트단위이기에 이게 무엇인지 알려줘야한다. 따라서 Content-type과 Content-length를 알려준다.

- 이렇게 정보를 보내주는 것을 MIME이라 하고, 인터넷으로 다양한 목적으로 메일을 주고 받는 것을 의미한다. 이메일 내의 컨텐츠와 첨부파일이 무엇인지 명시하는 프로토콜이다. 즉, 이메일 컨텐츠를 주고받는 것과 거의 다르지 않다. 

- 통신속도가 빨라졌기에 굳이 0과 1의 비트로 보낼 필요가 없어졌다. 또한 개발자들이 이를 보고 해석할 수 있도록하기 위해서 사람이 읽고 이해하기 편하도록 되어있다.

 

(4) URI

- 클라이언트가 서버에게 x라는 파일을 요청할 때 x를 어떻게 표현할 것인가가 중요하다.

- 인터넷에서 리소스를 찾아가기 위한 목적으로 어떤 종류의 리소스가 되더라도 이를 나타낼 수 있는 식별자를 만들었다. 따라서 Uniquely identifying해야한다. 또한 위치에 대한 정보도 포함되어야한다. 

- 위의 특징을 반영해 HTTP는 파일을 표현하기 위한 방법은 URL과 URN이 있다.

 

 

ex) URL 예시: https://www.example.com/index.html 

- https: 프로토콜

- www.example.com: 도메인 컴퓨터

- index.html: 디렉토리에 대한 위치

 

3) Transactions

(1) HTTP Messages

- HTTP request에서 URL을 사용해 정보를 요청하고, HTTP response로 그 파일을 전달하며 파일의 형태를 MIME으로 전달한다.

- TCP 이하에서는 프로토콜은 통신링크가 열악해서 헤더나 필드를 비트로 했지만 이후에는 알파벳을 사용한다.

- HTTP request에서 파일을 달라고할 때의 명령어는 GET이다. 또한 HTTP/1.0 버전에 준하는 파일이고, Host가 누구인지 보내준다.

- HTTP response에서 파일을 보내줄 때는 200 OK를 보내 GET이 성공했다고 알린다. 중복적인 의미이지만 200은 컴퓨터가 이해하기 편하고, OK는 사람이 이해하기 편하다. 또한 MIME에 준수하는 content-type과 컨텐츠의 길이를 보낸다.

 

(2) HTTP Methods

GET: 클라이언트가 서버에게 리소스를 요청한다. ex) 다운로드

PUT: 클라이언트가 파일과 이름을 서버에게 전달하면 서버가 전달받은 이름으로 파일을 저장한다. ex) 업로드

DELETE: 클라이언트가 파일을 삭제하라고 서버에게 요청한다.

 

(3) Status Codes

200: 요청을 성공했을 때 응답

302: 다른 사이트로 이동할 때 옮겨진 서버가 응답

404: 요청받은 파일이 없을 때 응답

 

(4) 기존의 웹사이트는 어떻게 사용할까

- 브라우저 내에서 하나하나 존재하는 컨텐츠들이 Resource이다.

- 네이버 홈페이지 같은 경우에는 화면 하나를 만들 때마다 매우 많은 리소스가 필요하다.(약 250개) 이때 서버 하나에서 리소스가 오는 것이 아니라 서로 다른 서버에서 컨텐츠를 가져오는 과정이 수반된다. 즉 네이버의 경우에는 250여개의 리소스가 서로 다른 컴퓨터에서 온다.

 

4) Message

- text/*: text포멧은 모두 받지만 Language는 영어나 프랑스어만 받을 수 있다고 전달한다.

- 클라이언트가 본인이 할 수 있는 것을 알려주고 이에 맞춰서 보내달라고 한다. 이를 header라고 한다. 

 

예시)

- 외부에서 공격이 가능할수도 있기에 서버에서 주는 정보는 지워지는 경우가 일반적이다.

- HTTP가 중요해졌기에 어떤 언어든 지원을 해야하지만 프로그래밍을 해서 서버와 클라이언트가 하는 동작이 달라질 수 있다.

 

5) Connections

(1) HTTP 프로토콜

- HTTP는 TCP가 Reliable하기에 TCP를 사용하도록 권장한다. HTTP는 신뢰성을 보장할 수 없기에 유실될 수 있기에 TCP를 쓰도록 했다. 따라서 TCP가 가지고 있는 문제점을 대부분 가지고 있다. 

- HTTP 1버전의 초기버전은 위와 같이 TCP/IP를 사용했다.

 

(2) Connections process

- 웹 브라우저 위에 URL을 입력한다. 이때 호스트 이름, 포트번호, 파일의 이름을 입력한다. 이후 DNS를 통해 joes-hardware.com에 대한 IP address를 가져온다. 이후 클라이언트는 서버와의 TCP 연결을 한다. 이후 HTTP request와 response를 한 뒤 연결을 해제한다.

- 연결과정이 길기에 다소 오래걸린다.

- 이와 같은 방식으로 flow가 진행된다.

 

6) Architectural Components of the Web

- HTTP 클라이언트와 서버 사이에 존재한다. HTTP intermediaries

- HTTP 1.1에서는 클라이언트와 서버 사이에서 보이지 않는다. 

- 웹 보안을 위해서 클라이언트가 서버에 접속하려 했을 때나 서버에서 클라이언트로 파일을 보낼 때 막는다. 

- 서버에서 보낸 첨부파일이 문제가 있을 것 같은 경우에는 이를 클라이언트에 보내기 전에 막기도 한다.

- 클라이언트가 디도스처럼 많은 요청을 남발하는 경우에는 Proxy에서 차단도 할 수 있다.

- Application integration을 통해 추가적으로 무언가를 할 수 있다. 예를 들어 Proxy를 통과한 경우에는 인사기록에 남도록 기능을 추가할 수 있다.

- 클라이언트가 외부에서 서버에 접속할 때 네트워크 상황이 안좋다면 Proxy가 그곳으로 보내는 컨텐츠는 압축해서 컬러를 흑백으로 바꿔서 보낼 수 있다. 혹은 대표적으로 다른사람이 이전에 가져간 컨텐츠였다면 서버가 아닌 본인이 Response를 보내는 캐쉬 기능 등을 통해 성능을 늘릴 수 있다.

 

ex) 귀하가 접속하고자 하는 브라우저는 대한민국에서 접속이 불가능합니다. 

 

7) More Methos 

(1) GET

(2) PUT

- response할 때 파일이 저장된 url을 보내준다.

 

(3) DELETE

 

 

(4) HEAD

- HEAD는 request를 보낼 때는 GET과 동일하다. 다만 response에서는 파일 본체를 보내지 않는다. 따라서 reponse에서 파일을 보내지 않고, 파일을 제외한 정보를 모두 보낸다. 파일을 받으려고했을 때 파일이 변했는지 아닌지, 파일 사이즈, 파일 정보 등을 미리 알 수 있다.

 

 

(5) POST

- 파일이 아닌 글자와 같은 데이터를 클라이언트가 서버에게 보낸다. 데이터를 전달하고자할 때 클라이언트는 POST 메소드를 사용한다. 소프트웨어 간의 정보를 주고받을 때 사용할 수 있다. 입력 파라미터를 전달받는 경우에는 POST를 사용할 수 있다.

 

(6) TRACE

- Proxy가 있는지 없는지 확인하는 용도이다.

- Proxy를 지나면 Via를 만들어서 서버는 이를 전달받고 그대로 response한다.

- Proxy가 TRACE를 통해 드러날 수도 있지만 일부러 드러내지 않는 경우도 존재한다.

- 디버그 목적이면 좋은 명령어다.

 

(7) OPTIONS

- 서버가 지원하는 옵션을 알려준다.

- Allow로 가능한 메소드를 보낸다.

- 보안상의 이유로 이를 알려주지 않는 경우가 많다.

 

8) More Status Code

(1) Redirect

- 요청한 것이 무엇인지는 알겠지만 다른 사이트로 가세요~라는 의미로 301 OK가 쓰였다.

 

(2) Request redirect

- If-Modified-Since 날짜 이후로 수정이 있다면 파일을 준다. 수정이 없다면 브라우저는 reponse를 받지 않고, 본인 컴퓨터에 로컬 캐쉬되어있는 것을 가지고 보여준다.

- 굳이 기존에 가져온 것이 바뀌지 않았더라면 로컬 캐쉬되어있는 것을 다시 사용한다.

 

 

---

2. Web Browser as Development Tool

1) Firefox의 개발자도구 

- CSS, 자바스크립트, HTML, 저장소, 쿠키, 임시 저장소 만들기 등 확인할 수 있다.

 

 

2) Chrome의 개발자도구

- 단말기도 선택하거나 Firefox의 개발자도구에 있는 것들도 사용할 수 있다.

 

 

---

3. Web Server Development

1) 소프트웨어를 사용한 웹서버

- 위의 세 소프트웨어를 사용해 웹서비스를 만들 수 있다.

- 설치하고 configuration을 마치면 사용할 수 있다.

- Static한 컨텐츠를 제공하거나 난이도가 높지 않은 Dynamic 컨텐츠를 제공할 때 이를 사용하는 것이 편리하다.

 

2) 프로그래밍을 활용한 웹서버

- 직접 프로그래밍 언어를 통해 만들어 웹서버를 만들 수 있다.

- 딱 해야할 로직이 있는 경우에는 이를 사용해 많이 이용한다.

- 메세지를 주고받기 위한 것은 HTTP, 서버에서 해야하는 것은 로직을 주고 받는 것이다.

- 빌트인으로 HTTP가 들어가있기에 이를 사용할 수 있다.

- 하지만 C++은 이를 빌트인으로 제공하지 않기에 서드파티 라이브러리를 구해야하기에 난이도가 높다.

 

예시)

- 자바 스크립트를 활용한 서버 구현

- 컨텐츠는 Hello world이다.

- 바인딩 소켓과 같은 것을 listen을 통해 구현할 수 있다.

 

예시 2) 

- Proxygen으로 C++만큼의 속도를 낼 수 있는 언어로 페이스북에서 만들었다. 아파치 서버로 만들었을 때보다 10배의 성능을 지닌다.

 

---

4. Web based Mobile Application Development

1)  Codova

- 정적인 표현밖에 못하는 HTML을 보완해 동적인 표현도 할 수 있는 자바스크립트가 등장해 점점 개혁을하기 시작했다. 

- 자바스크립트는 화면을 채우는 용도로 시작했으나 어플을 만드는 언어로 자리잡는다.

- Cordova 툴을 사용해 자바스크립트와 html, css로 모바일어플리케이션을 만들 수 있게 됐다.

- 오픈소스로는 Cordova이름으로, 본인들은 PhoneGap으로 브랜딩하여 공개했다.

- 웹브라우저에서 벗어나서 platform 독립적으로 동작하게 됐다.

- Xamarin: 휴대폰 위에 올라가는 어플리케이션을 개발할 수 있도록 한다.

 

---

5. HTTP 2.0

1) 개요

- HTTP 1버전의 문제점에 대한 해결책이 왼쪽이다.

- HTTP 1은 읽거나 디버그하기 좋지만 텍스트를 사용하기에 처리 속도가 느리다. 애시당초 0과 1로 보내 이를 더 빠르게 동작하게끔한다.

- HTTP 1은 매우 많은 양의 리소스를 하나씩 순차적으로 request받고 response를 하여 속도가 느리다. 또한 1개가 막혀서 안간다면 원하는 것을 받기까지 매우 오래 걸린다. 이에 따라 HTTP 2는 요청된 순서대로만 보내지 않고 준비되면 바로 보낼 수 있게하는 Multiplexing을 사용한다. 또한 이는 우선순위를 설정해 보낸다.

- 바이너리로 한다는 것이 해석시간 뿐만 아니라 사이즈도 줄어든다. 바뀌지 않고 반복적으로 사용하는 메세지는 매번 보내지 않고, 1을 보내 처리해야하는 부하를 줄이기도 한다.

- request를 보내지 않으면 response를 하지 않는다. 하지만 클라이언트가 요구할만한 것들을 미리 보낸다. 따라서 광고도 보낼 수 있게된다.

- 위와 같은 특징으로 HTTP 2.0을 초안과 오픈소스 소프트웨어는 구글이 만들었다. 이를 기반으로 표준을 만들었다. 또한 요즘은 HTTP 2.0을 많이 사용한다.

 

 

2) Binary protocol

 

- 텍스트 기반을 비트 기반으로 바꾼다.

 

 

 

3) Multiplexing

- 순차적으로 받은 것에 의해 되지 않고, 서버가 준비되면 바로 보낸다.

 

4) Header compression

- 바뀌지 않는 헤더 값을 인덱스로 만들어 관리한다.

 

5) Server Push

- 요청받기 전에 필요하다고 생각되는 리소스를 미리 전송한다.

 

 

 

 

 

 

---

6. HTTP 3.0

- 현재 완료되지는 않았지만 소프트웨어가 더 빠르기에 상당량 완성되고 있다.

 

1) QUIC이란?

(1) 개요

- HTTP 3.0은 QUIC이라고 불리는 프로토콜을 기반으로 만들어지고 있다. 

- QUIC은 UDP를 기반으로 하고 있고 오픈 소스로 공개되어있다.

- 2018년 말에 HTTP와 QUIC working group이 만나서 HTTP/3이라는 이름으로 만들었다.

 

(2) 개념

- TCP 위에서 HTTP를 돌렸더니 발생하는 문제점이 여럿있는 것 같기에 UDP 위에서 HTTP를 돌리는 것을 고려했다.

- HTTP 2.0을 베이스로 삼았기에 multiplexing과 압축 등과 같은 것을 사용해서 TCP가 가지고 있는 문제를 개선하는데 주 목적을 두었다.

- TCP를 개선하는 것이었는데 첫번째로는 Connection 시간과 Transport 시간(Flow control, congestion control), bandwidth estimation에서 개선을 하고자 했다.

- 4계층은 Unix와 Linux 커널에 들어가있다. 결국 TCP나 UDP의 성능 개선을 위해선 운영체제의 커널을 건드려야한다. 또한 외부 회사와의 협업을 해야한다. 이를 위해 커널 위에서 구성해야한다는 부담감을 빼낸다. 이때 TCP가 아닌 UDP만 사용하기에 표준화된 trasport 계층에서 기대할 것이 없다는 의미이다. QUIC은 커널이 아닌 user space, 일반 어플리케이션처럼 돌아간다. 

- UDP를 썼지만 에러 검출 및 복구는 어플리케이션 Layer에서 사용한다.

 

2) 특징

(1) Fast Extablishment

- TCP를 건드리기 어려우니 암호화 프로토콜인 TLS에서 레이어를 쌓아서 암호화와 보안과 같은 작업을 추가적으로 한다. 

- TCP의 연결 설정 시간이 매우 오래걸린다. QUIC은 이 모든 것을 한번에 묶어서 사용할 수 있다. 굉장히 간단하게 진행된다.

- 연결설정을 할 때 100ms, 이후에 반복적으로 연결을 사용하는 경우에는 0ms가 걸린다.

- 웹서비스를 할 때는 100ms 이내에 해야한다. QUIC은 어마어마하게 빠르게 동작하는 것이다.

- 이렇게 시간을 벌면 다른 곳에서 사용할 수도 있다.

- 이에 따라 사용자는 체감 시간이 매우 빠르게 된다.

 

(2) Enhanced Error Correction

- QUIC은 UDP를 사용하지만 TCP에서 사용한 Multiplex를 UDP에서 구현하며 조금 더 개선한다.

- 하나의 TCP 연결을 통과해야하는 경우 중간에 문제가 발생하면 멈출 수밖에 없다.

- QUIC은 UDP를 썼고, 한줄로 가지 않기에 에러 검출 및 복구는 각각의 줄에서 진행하기에 하나 때문에 전체가 느려지는 것을 방지한다.

- QUIC은 IP 위에 UDP만 사용하고 운영체제 위에서 어플리케이션처럼 돌아간다. 이 안에 에러 검출 및 복구를 위한 Loss recovery

- 트렌스포트 레이어에 대한 시큐리티, 멀티스트리밍이 올라간다. 그 위에 QUIC이 올라간다.

- HTTP2는 TLS도 그 중간에 올라가는 경우가 많다.

 

(3) Application Space Execution

- Quic은 커널이 아닌 그 위에 개발이 이루어졌다. 성능문제가 나올 수 있다. 커널 아래에 있는 애들끼리는 밀결합되어있어서 오버헤드가 적지만 QUIC은 어플리케이션이기에 오버헤드가 발생할 수 있다. 하지만 이러한 부하가 그렇게 크지는 않다. 이에 따라 일부 성능저하가 발생할 수 있지만 운영체제에 넣지 않은 어플리에키션 레이어이기에 자유도가 더 늘었다. 

 

(4) Client Deployment

- 크롬브라우저에 디폴트로 들어가있기에 http #quic으로 치면 이를 켤수도 있다.

 

(5) Server Deployment

- 언어별로 레퍼런스가 배포된다. 

- Go 언어를 가지고 QUIC으로 만들어졌다.

- HTTP 서버를 만드는 회사들이 동참하고, 본인이 상용화하는 소프트웨어 중 상당량을 QUIC을 도입한다.

 

3) QUIC 도입 결과

- 소프트웨어만 바꿨음에도 성능은 약 30% 증가했다.

 

4) 지금은?

- 구글의 클라이언트인 안드로이드 운영체제와 크롬 브라우저, 크로미움에 있고, 유튜브나 구글 사이트가 QUIC을 대량으로 도입한다.

- 실제로 현재 유튜브를 쓰거나 구글 서비스를 사용하고, 크롬브라우저나 안드로이드를 사용하면 밑에서 최적의 순간에 QUIC을 이미 사용하고 있다.

- 상당량의 성능 개선이 있다고 보고되고 있다.

- 구글이 돈도 안되지만 안드로이드, 크롬을 만드는 것은 굳이 표준을 고려해 무언가를 만들 필요가 없기 때문이다.

 

- QUIC은 급속도로 증가하고 있고, UDP를 했을 때 효과를 극대화할 수 있는 비디오에서 매우 큰 장점을 제공하며 확산되고 있다.

 

---

7. SIP

1) 개념

(1) SIP

- SIP는 Session Initiation Protocol을 의미한다.

- 인스턴스 메신저 프로그램, 화상 등 줌, 카카오톡, 라인, 구글 미트 등이 연결해서 통신을 시작하여 주고받는 것이 세션이다.

- RTP는 실시간으로 채팅이나 파일 전송할 수 있다.

- HTTP에 감명받아서 만들어졌다.

- 영어와 숫자로 함께 내용을 보내고, 

- IP 주소, 요청 정보, 오디오와 비디오 정보 등을 보낸다. 

- Invite를 할 때 오디오와 비디오 능력, 즉 미디어 정보는 SDP에서 별도로 정의했다. 그 외의 INVITE, 200 OK와 같은 것은 SIP에서 포함하고 있다.

 

(2) SDP

- offer의 a 중 하나를 골라서 이를 answer에서 a로 보낸다.

 

2) 절차

- 연결설정을 거쳐서 위의 과정을 거친다. 

- Invite와 Bye를 보내 연결 설정 및 해제를 한다.

 

 

3) SIP Entities

(1) User Agent

- UAC(User Agent Client): 요구를 보내는 쪽

- UAS(User Agent Server): 요구를 받는 쪽

 

(2) Registrar

- 아이디를 사용하지만 정작 네트워크 주소를 알아야지 통신을 할 수 있다. 스마트폰은 매번 네트워크 주소가 바뀐다. 이에 따라 현재 사용하는 IP 어드레스를 알아야지 통신할 수 있기에 현재 IP 주소와 ID를 매칭시켜 등록하는 것이 Registrar이다. 카카오톡을 켜면 로그인할 때 한번 이루어지고, IP 주소가 바뀌었을 때에 변경하는 과정이 필요하다. 

- 휴대폰에 있는 카카오톡 프로그램은 주기적으로 네트워크 주소를 확인해서 카카오톡에 네트워크 주소를 보낸다. 이에 따라 수많은 서버가 필요하다. 이때 ID와 네트워크 주소를 저장하는 것이 Registrar이다. 

 

(3) Proxy Server

(4) Redirect Server

 

4) SIP Call Redirection

- 외국에서 스마트폰을 켤 떄는 한국 쪽으로 연결하는 과정이 수반된다.

- Alice가 INVITE를 날리면 Bob의 위치가 있을 것 같은 곳에 보내가면서 Bob을 찾는다. 

- 채팅방에서 여러명과의 통신을 한다면 해당 채팅방에 정보를 보내면 1대 N으로 퍼져나간다. 

 

 

---

8. Advanced Web Technologies

1) WebRTC

(1) 개념

- 웹브라우저 자체가 강력해지고, 이를 위해 사용하는 HTML, CSS, 자바스크립트 언어가 강력해지니 운영체제까지 내려갈 필요가 없어졌다. 

- 구글은 본인들이 하고 싶은 것을 크롬에서하기에 운영체제까지 내려가진 않는다.

- 웹 기반의 Real Time Communication

- ex) 웹 브라우저에서 구글 미트를 사용할 수 있다. 

- Peer to Peer로 서버가 없어도 사용할 수 있다. 문서작업을 하기에 표준이 있다. 웹 관련된 회사인 구글, 마이크로 소프트, 모질라, 오페라 등이 참여한다.

 

(2) 특징

- 데이터를 주고받고, 오디오나 비디오 모두 가능하다.

- SIP는 연결설정 및 제어하는 컨트롤 프로토콜이지만 WebRTC는 이를 포함해 오디오, 비디오, 컨퍼런스가 가능한 것까지 반영한다.

- DTMF: 전화를 누르면 소리나는 것

- 프로그래밍적으로 접근할 때 서버없이 찾고 연결해야하기에 이를 위한 RTCPeerConnection이 존재한다.

- 데이터를 주고 받을 때에는 데이터 채널이 있다.

- 화상으로 하기에 음성, 글자 등을 보내야하기에 MediaStreamTrack을 사용한다.

- 위의 기능이 웹브라우저에 들어가있다. 

 

- 많은 브라우저가 이를 지원한다.

 

(3) 참고 사이트

WebRTC

WebRTC API - Web API | MDN (mozilla.org)

 

 

2) asm.js

(1) asm.js란?

- 조금 사장된 언어이긴하다.

- asm은 Assembly 언어의 약자이다. 웹은 하드웨어를 건드릴 수 없지만 Assembly 언어가 붙었다. 이는 fourth language로 브라우저에서 natively 작동하게 한다.

- 웹 브라우저에는 가상 머신이 있다. 이 이유는 자바가 웹브라우저가 이해하는 가짜 기계어로 프로그램을 만들고, 웹 브라우저는 가상 머신이 있어서 이를 실행할 수 있다. 이러한 개념을 확장한다. C++ 또한 빠른 속도로 위의 매커니즘을 활용해 돌린다. 즉 컴퓨터로 돌아가는 코드도 웹 브라우저로 돌아가게 해준다.

 

(2) 참고 사이트

asm.js (asmjs.org)

WebAssembly

웹어셈블리 | MDN (mozilla.org)

 

 

3) Mixed Reality

가상 현실과 증강 현실 두 가지를 실어나르는게 웹 브라우저의 기능의 일부로 들어갔다.

(1) 어그먼티드 리얼리티

- 포켓몬고

 

(2) 버츄얼 리얼리티

- 가상현실

 

- 증강현실을 통해 귀신을 보고 싶다면 이를 받아서 투영해야하는데 이를 위해 웹브라우저를 사용한다.

 

(3) 참고 사이트

WebXR Device API (immersive-web.github.io)

Mozilla Mixed Reality | Home

 

cf) 웹브라우저가 머리에 쓰는 기기에도 블어간다.

 

 

4) Solid (Social linked data)

(1) 개념

- 기술이 가시적이지는 않지만 월드 와이드 웹을 만든 팀 버너스리가 만들었다.

- 새로운 웹의 세상이 필요하다며 Solid를 가져온다. 

- 개인의 정보를 모아 이를 기반으로 해서 중계해준다. 하지만 본인의 데이터를 제공할 때 돈을 주지는 않는다. 

 

 

(2) 아이디어

- 스마트폰을 통해 내 정보를 보고 싶다면 해당 정보는 나에게 있어야한다.

- 내가 관리하는 나의 저장소를 만든다. 

- 내 사진을 받고 싶다면 내게 허가를 받아야한다.

- 구글, 트위터, SNS와 같은 것에 대한 반기로 등장했다.

 

(3) 참고 사이트

Solid (mit.edu)

Home | Inrupt