지나가던 네트워크 분석장비 개발자입니다.

일단 컴퓨터 입장에서는 텍스트나 바이너리나 둘 다 2진수 숫자입니다. 우리가 ABCD라고 쳐봐야 컴퓨터는 0x41424344라는 숫자로 알아먹을 뿐이라는 거죠(=_=). 특히 전송장비 입장에서는 텍스트라고 특별하게 다르게 다루거나 그런게 전혀 없습니다.

아울러 HTTP/1.1에 보면 chunked encoding이란게 있습니다. 다운로드되는 전체 파일의 크기를 보내는게 아니라 이번에 보낼 뭉치(chunk)와 그 크기를 보내는 형태입니다. 이를테면......

1. 먼저 140 바이트 갑니다
2. 이번에는 4900 바이트 갑니다
3. 이번에는 2009 바이트 갑니다
4. ......
n-1. 이번에는 9000 바이트 갑니다
n. 마지막입니다. 0바이트 갑니다(=끝입니다)

이런 식입니다. 이 방법을 사용하면 HTTP에서도 스트리밍을 쉽게, 그리고 안정적으로 구현할 수 있습니다.
(일단 이론상으로는 그렇습니다. 실제 네트웍 현황을 보면 완전히 welcome to the hell이긴 합니다만......)

저는 010101 뿐이라도 텍스트/동영상은 차이가 있다고 생각하는게요.

동영상의 경우라면... 프로토콜을 아예
청크 크기를 다 1mb로 통일한다거나 해서
청크 크기를 굳이 주고받을 필요가 없는 프로토콜 개발이 가능하지 않을까?? 생각했어욥 ㅎㅎ
첫 5초는 풀스피드로 훅 밀어 넣은뒤
그 뒤로는 1초당 1.2초 분량의 비디오만 전송되게 한다거나 하는 것도 가능할것 같고?

http의 경우는 우선 html 받아오고, 해석한뒤에 js를 다시 서버에 요구해서 받고,
또 해석하다보니 css가 필요해서 또 받아오고 하는 식으로
서로 크기가 다른 청크의 텍스트 파일들을 랜덤하게 요청하고 받아오고 하는 식이기 때문에
프로토콜을 다르게 디자인하는게 속도향상이나 네트워크 장비의 부하 절감에 도움이... 되지않을까??

하는 식의 생각을 해본것.. ㅋㅋ
저는 비전공자라서 ㅋㅋㅋ 더 알려주심씨오 궁금합니다 ㅋㅋㅋ

위에 거진 답변이 적혀있네요. 동영상용 프로토콜에 대해서만 추가로:

프로토콜은 각 회선의 대문 같은거라서 용도에 따라 나누는 큰 Entity입니다.
HTTP와 HTTPS 둘다 그 용도는 브라우저를 통한 하이퍼텍스트 송수신입니다.
동영상이든 사진이든 뭐든 하이퍼텍스트로 이동이 가능합니다. 그래서 '데이터 형식'라는 소분류를 위해 프로토콜을 나눌 필요가 없습니다.
웹 초창기에도 이미지는 있었습니다. http를 통해 웹에서 뭐든 표현하는게 중요한거니까요.
프로토콜은 그냥 아키텍처 수준으로 생각하시면 됩니다.

그 데이터를 예전에는 동영상 파일로 임베드해서 표현할 수 있게끔했고, 그 브라우저가 영상 재생기를 들고 있었지만,
이제 stream기술이 매우 좋아져서 끊임없는 영상 재생을 chunk로 받아 표현할 수 있게된 것 뿐입니다.

과거에는 데이터 유형별로 프로토콜을 달리해야하는 것이 아닌가로 생각했고, 실제로 그러한 프로토콜들이 개발되어왔습니다. 하지만,
1) 생각하신대로 최적화된 프로토콜을 사용하는게 성능면에서는 가장 좋은지에는 이견이 조금 있습니다. 각 기능의 최적화가 네트워크 레벨(혹은 보다 넓은 범위)에서의 최적화로 이어질 것 이냐는 의미이지요. 또한,
2) 새로운 프로토콜을 개발한다면(어플리케이션의 라이브러리 제공정도로 충분할 수도 있겠지만), 해당 프로토콜들을 인프라레벨(대표적으로 운영체제, 넓게본다면 랜카드나 라우터도!)에서 지원을 해주어야만 합니다. 만약, 독자적 스킴을 사용한다면, 미들웨어가 들어가야하고, 이는 서버 인프라/클라이언트 모두에게 요구되는 사안입니다. 이미, 배포된 클라이언트들은 버전업 없이는 새로운 프로토콜을 사용할 수 없습니다. 공인인증서를 위한 미들웨어 프로그램 같은걸 생각하셔도 좋을 것 같아요.
2-1) TV와 같은 독자적인 망을 구축하는 것이 가장 이상적이겠으나, 이는 비용적인 한계로 쉽지 않습니다. 반대로 이쪽도 인터넷으로 들어오는 추세이지요. 마지막으로,
3) 사용하는 프로토콜의 수가 늘어날 수록 개발자가 고려해야하는 / 고민해야하는 / 공부해야하는 범위는 더욱 더 늘어나고 이는 운영 비용의 증가로 이어지게 됩니다.
따라서, 1) HTTP와 다른 프로토콜들을 다수 만들기 보다, http를 고도화 하고(텍스트만이 아닌 다양한 형태의 리소스를 전달할 수 있는 프로토콜로 개선하자), 그리고 이 위에서 동작하는 동영상 스트리밍 프로토콜을 만들자 2) HTTP를 쓰지 않고 L4 레벨에서 해결하자 라는 흐름으로 왔다고 이해하셔도 좋을 것 같습니다. 현재는 http의 성능이 많이 개선되어, http2는 하나의 커넥션으로 다수의 파일/영상 스트리밍이 가능한 멀티플렉싱 기능, 헤더의 간소화 등으로 성능이 많이 좋아졌습니다.
마지막으로 동영상은 동적인 QoS처리(유튜브의 자동 화질 변경과 같은)를 위해서 http위에 다른 프로토콜을 덧대는 형태로 많이 개발합니다. 대표적인게 MPEG-DASH인데, 사실 MPEG-DASH를 쓰기보다는 각 회사에서 허용하는 QoS를 위한 프로토콜을 갖고 있습니다.