통하였느냐? 통신에 대하여

설영환·2021년 9월 3일
0

들어가기 전 주의사항

  • 틀린 내용, 수정해야될 부분에 대한 비판은 언제나 환영입니다. 댓글로 달아주세요.
  • 대상은 비전공, 개발 처음하는 분들 웹을 거의 모르시는 분들을 위하여 어려운 단어를 최대한 배제하였습니다.
  • 다소 과장되었거나 축소하여 말을 하는 경우가 있는데 선을 넘었다 싶은 부분은 언제나 댓글로!
  • 하드웨어적인 부분(포트, 방화벽 등)에 대한 부분은 배제하였습니다 다음에 기회된다면 블로깅 해보겠습니다.

컴퓨터 통신의 시초

웹 통신의 시작

  • 제일 처음의 컴퓨터간 전기적 통신은 컴퓨터의 시작과 함께 두대간의 point to point 로 시작되었습니다.
  • 현대의 인터넷이라고 할만한 시작은 미국에서 군사용으로 정보관리를 위한 ARPANET이라고 합니다.
  • ARPANET은 군사전용이었다가 최초 4개 대학을 시작으로 야너두! 아냐두!를 시전하여 수많은 대학들이 연결되었고 미군은 민간으로 풀어서 민간 인터넷의 시초격으로 이야기되고 있습니다.

팀버너스리의 인트라넷 WWW 제안

위 사진은 팀 버너스리 입니다.
한국인도 아니면서 홍익인간처럼 모든사람이 인터넷을 널리 이용하게하라는 말을 남겨 웹표준과 웹 접근성이 생겼습니다.
프론트라 그거지키느라 죽이고 싶었더...ㄴ..

  • 팀 버너스 리는 전세계 중구난방이던 통신들을 www,url,http등을 고안해 내서 현재의 전세계적으로 통일된 규약의 웹을 사용할수 있게 되었습니다.
  • 여기서 이야기 해볼것은 http 에 관련된 것입니다.
    중구난방이었던 웹의 규약을 http로 통합하여 현대의 웹을 탄생시켰다고 해도 과언이 아닙니다.

웹 통신은 어떻게 하는거?

TCP UDP?

  • 이부분에 대해서 각각 을 설명하고 이야기 하면 머리 터질듯한 분들이 많을 듯하여 차이점만 사진으로 대체합니다.
  • 여기서 기억해야될것은 신뢰성과 속도만 기억하시면 됩니다.(아래에서 설명에 인용)
  • 초기에는 속도는 느리더라도 신뢰성이 중요했기 때문에 TCP를 사용

중간에 소실된다면..
hello nice to meet you -> hell_ __ to __ you
가 되는수가....

3-way handshake

  • 위 제목에 대한 것을 들어본적이 있는 사람이 있고 없는 사람이 있을것이긴 한데 간단히 말해 통신 전 연결 확인 작업을 생각하면 됩니다.
  • TCP는 신뢰성이 높다(위 차이 사진 인용)가 장점인데 일단 연결된 사람끼리 통신이 잘 이루어지는지 확인하여 신뢰성을 높이는 작업이라고 생각하면 됩니다.
  • 위의 그림에서 어려운 영어단어들은 다 빼고 #1, #2, #3 만 설명하면
    #1 - 클라이언트에서 서버로 야 너 통신 준비 되었냐?라고 물어보는 겁니다.
    #2 - 서버는 준비 되었는지 응 준비됨 회신 기다릴게라고 확인과 통신을 기다릴거라는 회신을 합니다.
    #3 - 클라이언트는 이후에 오키 이제 보낼꺼야라고 회신을 합니다.
  • 위의 3경로로 통신을 준비하기 때문에 3-way라고 하는 이름이 붙었습니다.

통신은 회신을 보내지 않으면 중간에 없어졌는지 알길이 없기 때문에 ACK라는 회신을 항상 보내야됩니다.

데이터 전송은?

  • 데이터는 쪼개서 패킷으로 보내집니다.(패킷은 그냥 쪼갬의 단위라고 보셔도 무방)

ex> 독일에서 블라디 보스톡으로 맥주 10만 배럴 보내주세요! 라는 리퀘스트가 왔을때
response Data는 한번에 10만 배럴을 수용할수도 없고 수용하다가 문제가 생기면 싹다 잃기 때문에

  • 배로 각 1만 배럴씩 5대
  • 비행기로 5천 배럴씩 6대
  • 육로로 2만 배럴 1대

전송 끝? 4-way handshake

  • 전송의 시작을 3-way handshake로 했다면 전송을 종료하는 단계는 4-way handshake로 합니다.
  • 전송이 마무리 됨을 알려야되고 서버에서도 무한정 기다릴수 없기때문에 데이터가 전송되는 즉시 종료합니다.
  • 이번에도 #1, #2, #3, #4만 이야기 하자면
    #1 - 전송이 종료됨을 알리는 신호를 클라이언트가 서버로 보냅니다.
    #2 - 그럼 그 신호를 잘 받았다고 알리는 회신을 합니다.
    #3 - 이후 서버에서는 통신을 종료하고 종료됨을 알리는 신호를 클라이언트에게 보냅니다.
    #4 - 클라이언트는 종료 신호를 잘 받았다고 다시 서버에 회신을 보냅니다.

계속 통신할순 없어? (소켓!)

  • 일반적인 웹 통신의 문제점은
    • 클라이언트만 리퀘스트를 보낼수 있다.
    • 실시간이 아닐수있다.

이를 해결하기 위한 방법으로 소켓을 많이 이용합니다.
실시간이고 데이터가 많아질수 있어 문제점은 존재하지만 스트리밍에서 많이 사용됩니다.
웹에서는 실시간 채팅 및 실시간 알림에서 많이 사용됩니다.

Http? 뭐야 그게

  • 간단히 말해 통신을 위해 서로 약속된 규약입니다. 대한민국에서 220 볼트의 전기를 쓰기로 약속되어있기 때문에 모든 가전기기들이 220볼트에 맞춰서 나오는거 처럼 서로간의 약속으로 인하여 모든 사람이 통신할수있도록 규약을 만들어 놓았습니다.

http 0.9

  • 초창기 http 는 versioning이 없었고 0.9부터 제대로된 버전이 생겼습니다.
  • 헤더가 없습니다. (따라서 method가 없고, get만 가능했습니다.)
  • 헤더가 없으므로 파일양식은 html을 제외하고는 전송이 불가능했습니다.

O라고 전송이 온다면 이게 숫자 0인지 영어 O 인지 그냥 그림인지 알길이 없으니.. 가장 단순한 html만 전송가능하게 했습니다.

http 1.0, 1.1

  • 어려운 거 다빼기 위해 1.0만 설명하겠습니다. (1.1을 넣은 이유는 1.1통신으로 15~16년을 지속했기 때문에..)

  • 1.0으로 넘어오면서 통신에 header가 생겼다는게 가장큰 변화점입니다.

    이전까지는 기어가 바나나랑 수박 2개를 샀다
    -> 기어좌는 바나나 1개 수박 2개를 구매해서 총 3개를 구매했다만 가능했던게
    -> 헤더에 정보를 담아 (바나나는 사람임)
    -> 기어좌는 바나나라는 친구와 수박 2개를 구매해서 총 2개를 구매했다 라고 전송도 가능해짐

  • 헤더는 확장 가능성이 높았고 헤더에 점점 더 많은 정보들을 넣을수 있게 되어 다양성이 늘어나게 되었습니다.

http 2.0

  • 문제점
    • 전송이 진행되면 하나의 전송이 끝날때까지 다른 전송은 하지 않는다!(대안들은 있지만 여기서 설명 X)
      ->느리다
    • 헤더의 확장이 15년간 지속되면서 헤더가 터질 지경!
  • http2.0에서 달라진점
    • 헤더의 압축(정보를 압축하기 시작)
    • Multiplexing Streams
    • Stream Prioritization

http 3.0

  • tcp? 느려! udp쓸꺼!
  • 신뢰? 3악수? 갖다버려! 일단 보내면 뭐 잘받으면 답장오겠지!
  • 주소? 그게 뭐임? 한번 통신하고 통신되었던데 또 보내면 되는거아님?

http 2.0? https?

  • 가끔 https를 http 2.0으로 쓰시는 분들이 있어서 간단히 설명
  • http + secure = https!
  • 전송시 암호화 하고 도착시 복호화 하여 중간에 탈취가 되더라도 안전하게 보안에 신경씀

ref

profile
Frontend 를 목표로합니다.

0개의 댓글