[javascript] HTML5를 사용하면 웹 앱이 P2P HTTP 연결을 만들 수 있습니까?

Program / 글쓴이

중앙 서버의 도움으로 동일한 웹 앱의 다른 사용자와 직접 연결을 만들 수있는 웹 앱을 만들 수 있습니까? UDP 홀 펀칭과 유사한 프로세스를 상상하고 있습니다.

HTML5의 새로운 WebSockets API에 대해 읽었지만 전이중 연결을 시작하기 전에 WS 호환 서버와의 연결을 시작해야합니다. 나는 서버가 초기 핸드 셰이크 에만 관여하는 클라이언트 간의 직접 연결을 만드는 프로세스에 대해 더 많이 생각하고 있습니다 .

참고 : Java 애플릿은 포함되지 않습니다. 표준 브라우저 기술에만 관심이 있습니다.

답변

지능적인 추측 대신 정보에 입각 한 답변이 있습니다.

HTML 5는 자바 스크립트에서 피어 투 피어 연결을 허용 할 계획이지만 이러한 연결은 RAW TCP가 아닙니다.

전체 사양은 http://dev.w3.org/html5/websockets/ 에서 찾을 수 있습니다.

jrh

편집 : 피어 투 피어 연결에 대한 특정 참조와 함께 다음 링크를 확인하십시오.

기능이 여전히 협상 중이라는 점에 유의하는 것이 중요합니다. “로컬 채팅”웹 앱을 만들 수 있으면 좋을 것입니다. 🙂

jrh

답변

업데이트 10/17/2012 : 이 기능은 이제 Chrome Stable v22에 있습니다. Chrome에서이 기능을 사용하려면 chrome : // flags에서 두 개의 플래그를 활성화해야합니다.

  • MediaStream 활성화
  • PeerConnection 활성화

그런 다음 AppRTC 데모 페이지 를 방문하여 데모 를 사용해 볼 수 있습니다 . 피어 투 피어 기능을 사용하고 장치 캡처를 활성화하도록 Chrome을 설정하는 방법에 대한 자세한 지침 은 WebRTC-데모 실행 페이지를 참조하십시오.

업데이트 : Ericcson Labs의 엔지니어는 HTML5 피어 투 피어 대화식 비디오 를 수행하는 WebKit 빌드에 개념 증명을 가지고 있습니다 .

그들은 기술이 작동하는 방식에 대한 다이어그램과 설명뿐만 아니라 작동중인 기술에 대한 데모를 블로그에 게시합니다.

그들은 이것을 안정화시키고 WebKit 저장소에 커밋하기 위해 노력하고 있습니다.

답변

네, 드디어.

이 글을 쓰는 현재 (2017 년) WebRTC는 현재 대부분의 최신 브라우저 (사용중인 브라우저의 약 70 %)의 표준 부분이며 멀티미디어 스트리밍, P2P 및 홀 펀칭을 허용합니다.

WebRTC에 대한 문서, 샘플 코드 및 라이브 예제는 html5rocks.com 에서 찾을 수 있습니다 .

caniuse.com 및 html5rocks.com 에 따르면 다음 브라우저는 WebRTC를 지원합니다.

전체 지원 : Edge 14, Firefox 22, Firefox Android 55
부분 지원 : Android 브라우저 56, Chrome 20, Chrome Android 29, Edge 12, Firefox 17, Opera 18, Opera Android 20, Opera Mobile 12, UC 브라우저 Android 11.4
향후 지원 ( 2017 년 3 분기) : iOS 11 용 Chrome, iOS 11 및 OS X 10.11 용 Safari 11
지원 없음 : IE, IE Mobile, Opera Mini

Safari 11이 아직 출시되지 않았고 iOS 11 또는 OS X 10.11이 필요하기 때문에 WebRTC의 포화 속도는 Apple 기기에서 제한됩니다. 과거의 업그레이드 추세에서 예상 할 수 있지만 WebRTC는 2018 년까지 약 75 %의 iOS 장치에서, 2020 년까지 100 %에서 사용할 수있을 것입니다.

답변

이것이 까다로운 이유는 여러 가지가 있습니다.

  1. 방화벽 (일반 NAT 일지라도)은 HTTP보다 훨씬 낮은 프로토콜 계층에서 이러한 종류의 연결을 어렵게 만듭니다. 내 IT 보안 모자를 쓰고 있으면 웹 사이트를 방문하는 것만으로도 컴퓨터에서 임의의 포트를 여는 멋진 방법처럼 보이므로 사실상 모든 기업 IT 시스템에 의해 공격적으로 차단됩니다.
  2. HTTP는 본질적으로 클라이언트-서버 프로토콜입니다. 긴 폴링 (및 몇 가지 다른 기술)을 사용하여 이중 통신을 시뮬레이션하는 것은 합리적으로 쉽지만 특히 효율적이지는 않습니다.
  3. 이것은 XSS 공격을위한 큰 구멍을 열 것입니다.

WebSockets는 이러한 문제 중 두 번째 문제를 해결하도록 설계되었지만 다른 두 문제는 해결되지 않았습니다. HTML5 사양에서 피어 투 피어에 대해 이야기 할 때, 그들은 클라이언트와 다른 클라이언트 사이가 아니라 서버와 클라이언트 사이의 전이중 통신에 대해 이야기하고 있습니다.

그러나 웹 소켓 위에 적절한 네트워크 스택을 구현하는 것은 간단합니다. 단, 모든 통신은 여전히 ​​서버를 통해 수행되어야합니다. 나는 이것이 긴 폴링을 사용하여 수행되는 것을 보았습니다 (Uni의 친구가 긴 폴링을 사용하여 전체 TCP / IP 스택을 작성했습니다).

답변

두 번째로 harshath.jr : 디렉터리 역할을하는 서버를 가질 수 있습니다 (연결된 각 에이전트의 “원점”을 노출합니다. origin은 draft-abarth-origin 에서와 같이 scheme + host + port 이며, 스키마는 “ws”입니다.) 또는 “wss”). 그런 다음 피어 투 피어 WebSocket 연결을 시작할 수 있습니다. SOP는 덕분 통해 작업중인 CORS . 물론 이는 각 에이전트 (예 : 브라우저)가 자체 WebSocket 서버 (Opera Unite)를 포함해야 함을 의미합니다.

그 동안 XMPP / IRC / etc.-way : 피어 투 피어 연결은 없지만 중앙 서버 (또는 네트워크!)에 대한 WebSocket 연결을 통해 연결된 에이전트에 메시지를 전달합니다 (결국 특정 WebSocket 사용 ” 하위 프로토콜 “)

편집 :이 모든 것이 실제로 HTML5의 범위를 벗어납니다 (이 모든 것들은 한때 HTML5의 일부 였지만 자체 사양으로 분리되었습니다).

답변

웹 소켓의 전체 아이디어는 방화벽 및 프록시 http://www.kaazing.org/confluence/display/KAAZING/What+is+an+HTML+5+WebSocket 의 문제를 해결하는 것이 었습니다 .

답변