9주차 필기 - transport layer(1)

요즘은 http 기반으로 어플 많이 짠다.

이게 웹 브라우저와 웹 서버 간에 정보를 주고받는 기술…

파이썬, 자바스크립트 같은 최근 언어들은 http를 쉽게 쓰고 정보를 주고 받을 수 있음.

씨플로 http 하는 건 엄청 힘듦. 고난도 기술.

Tcp, udp 위에서 플밍을 하는 경우가 점점 없어짐.

단순하게 호출하면 인스턴스 메시지를 발신/수신하는 어플리케이션도 몇 줄 짜면 바로 구현이 됨. 이게 제로 메시지 큐.

오늘부터는 어디에서 뭘 하든 간에 네트워크가 끊어져 있지 않다면, 이름을 이해하고 한번쯤 동작 시켜 보고 회사에 응용하는 입장에서 관심을 많이 기울여야 한다.

3쪽: 떨어져 있는 컴끼리 통신하는 것이 호스트 투 호스트.

피지컬 & 데이터링크 계층은 떨어져 있는 2개 노드 간 통신을 하는 역할이었다면,

컴퓨터 간의 통신이 가능했던 건데, 이제는 컴 위로 올라감. 운체 안으로 들어가면 운체 속 프로그램들인 프로세스들이 통신하는 것이 4계층은 프로세스와 프로세스 간의 통신을 하게 된다.

4: 저 노드 투 노드가 바로 맨 아래 두 개 계층 간의 통신이다.

피지컬&데이터 링크는 어플리케이션 상의 프로세스 간 통신을 담당. 노드 투 노드.

컴퓨터에서 나간 정보가 반대쪽 컴으로 가는 게 호스트 투 호스트.

a프로그램이 b프로그램에게 주는 게 프로세스 간 통신임.

이제 소웨 도메인, 어플 쪽으로 올라간 것. 피지컬/하드웨어적인 정보가 아니다!!

5: 동작을 요구하는 주체가 클라이언트, 기능을 제공하는 주체가 서버다!!! 즉, 서버는 서버만, 클라이언트는 클라이언트 기능만 하는 것이 아니라는 점.

이젠 폰에도 웹 브라우저를 구동시키기가 쉬워졌다. 크로스 플랫폼(자스 CSS html)로 만든 앱을 크로도바, 폰갤을 통과시키면 아무 운영체제에서나 도는. 외부 모듈은 http 서버. 다른 친구들이 웹 서버처럼 접속할 수 있음. 뭐 이렇게 하는…

블록체인은 클라이언트, 서버도 없고 분산 처리라고 하여 지들끼리만 통신한다.

로컬 호스트 = 내 컴퓨터

네트워크 주소를 뭐라고 하냐면, 전세계에서 주는 유니크한 주소. 그 안의 프로그램 역시 유니크한 주소를 갖게 된다(프로세스 주소) -> 진정한 유니크.

상대편의 remote process 주소를 더하면 전세계에서 유니크한 그 컴의 그 플을 찾을 수 ㅇ

Transport layer에서 주는 고유한 뭐의 주소가 포트 넘버. 보통 한 컴에서 줄 수 있는 주소는 16비트어치. 포트 넘버는 플이 실행될 때 운체가 준다. 0번부터 1023까지 1024개는, 매우 많이 쓰는 네트워크 기능들을 정의해뒀다. 따라서 10자리 넘어가는 자리부터 플에 대한 그 유니크한 넘버를 주기 시작한다. 회사에서도 자기가 만든 프로그램도 본인이 번호를 줘야 한다.

Tcp, udp 포트 넘버… 유명한 프로그램들은 이 번호가 이미 등록이 되어 있다.

sdn에서도 마찬가지. 우리가 쓰는 프로그램이 있으면 ~를 최우선으로 처리한다. 이런…

이를테면 로봇간 통신 최우선, 업무 프로세스는 둘째, 네이버 같은 것에 대한 접속은 우선순위 젤 낮게.

그래서 그만큼 포트 넘버는 중요하다. 포트 넘버가 바뀌면 서비스가 무너지는 경우도. 회사에서 화상 회의를 할 때도 굉장히 복잡. 뭐가 안 맞으면 통과를 안 시킨다.

5: Client/Server Paradigm

The most common process-to-process communication is though the Client/Server Paradigm

 

7: 52000, 13은 다 주소에 해당한다.

단, 클라이언트는 내가 접속을 시도하는 애지만, … 서버 쪽은 포트 넘버가 정해져 있다. 그러나 본인의 포트 넘버는 랜덤 넘버

8: IP + 포트 넘버 -> 세계 유일 주소. 이를 부르는 다른 이름이 바로 소켓 어드레스. 보통 hexa로 쓴다는 점.

10: 멀티플렉서 안에 전송 계층이 있다.

결국 전송 계층은 프로그램의 식별. 그리고 가장 중요하면서도 복잡한 기능이 멀리 떨어져 있는것 간의 에러 검출 및 복구 기능. 만약 이 기능을 하겠다고 하면, 연결 설정 과정과 해제 과정을 거친다. 데이터링크 계층도 비슷한 기능을 했었는데, 이게 발전해서

11: 커넥션리스. 잘 받았고 못 받았고 검사하는 것도 없음. IP는 데이터링크 방식이며, 앞뒤에 뭐가 있는지 상관없이 걍 보낸다. 에러 검출 따위 없다.

TCP는 우리가 전공을 하든 말든 매일 사용하고 있다. 안전성이 중요할 땐 SCTP를 사용. 서로 다른 프로세스를 연결할 때 한 줄이 죽어도 다른 줄이 사용할 수 있게 멀티줄을 사용하는. TCP는 일반적으로 사용하는 녀석.

그냥 이 파트는 슬라이드 참고할 것. 복붙이 영 퀄이 안좋아.

12: Reliable - 에러 검출 및 복구를 한다는 뜻. 단, 이걸 하면 속도가 느리고 복잡. 즉, 메모리를 많이 잡아먹고, 컴퓨터 제어가 힘들어진다. TCP의 단점. 그래서 다음 시간에 UDP 위에서 자기들이 필요한 에러 검출만 스스로 하자… 이렇게 되어, 아프리카 티비 같은 게 이렇게 만든. 별풍선. 이런 통신 기법이 여기서 나온 것.

TCP는 부하가 커서, Go는 언어 자체가 이것의 오버헤드를 줄이는 것을 한다. 고가 서버 언어. c계열 성능을 뽑으면서 고의 지나친 단순함을 보완하여 RUST라 등장!!!!!!!!!!!!

학부 시절에 이런 것들을 많이 건드려봐야. 노트북 위에서 짜는 경우가 많을 텐데, 노트북 위의 윈도우 위에서 프로그램을 짜기 위한 개발 환경을 얘기하자면… 이 윈도우 위에서 무슨 언어, 무슨 도구로 회사 어플을 짤 건지 얘기할 수 있는 사람은-? Gcc는 씨플플 컴파일러래. C 컴파일러는 컴팩트한 씨 컴파일러를 제공하는 경우에는…. 통상 씨플 컴파일러에 옵션이 더해진…

윈도우에서 하는 경우에는 어떻게 하면 되는가… 씨플플을 갖고 마소 위에서 플밍을 하는 것은 본사에서도 권장하지 않는… 마소는 씨샾을 권한다는 점!!!! 네트워크는 무저건 자스. 이게 네트워크 프렌들리한 녀석.

13: udp = unreliable. 필요한 것 맞다. 2계층도 이미 에러 검출을 하는데 왜 4계층에서도 똑같은 일을 하느냐?

The network layer in the Internet is unreliable (best effort delivery), we need to implement reliability at the transport layer

14: 신뢰성을 더 보장해야 한다는데…  2계층에서 하는 것만으로 불충분하기 때문. 완벽하지 않으니까. 물론 이렇게 두 번 거쳐도 와안전 에러 프리한 것은 아니다.

17: The User Datagram Protocol (UDP) is called a connectionless, unreliable transport protocol. 유저 앞뒤 상관없이 데이터그램을 주고받는 유저 프로토콜. 포트 넘버를 알아야만 전송가능한 호스트 투 호스트 작업이 필요하니까. 에러 검출 및 복구도 안하고 걍 보내기만 하니까 필요함.

If UDP is so powerless, why would a process want to use it? Very simple protocol using a minimum of overhead

- if a process wants to send a small message and does not care much about reliability, it can use UDP

- if it sends a small message, taking much less interaction between the sender and receiver than it does using TCP

그래서 TCP/UDP/제 3의 길(아프리카티비 같은 거)을 갈 것인지를 선택해야 함.

18: 방송국 같은 브로드 캐스트는 걍 보내니까 udp 쓴다. 그러나 유튜브나 넷플릭스처럼 뭐가 복잡한 데는 TCP를 쓴다.

5초 광고 뜨는 동안 그만큼 미리 영화를 받아 둔다. TCP를 쓰면 에러 검출 및 복구를 해 나가면서 보는… 그러면 사용자 입장에서는 끊어지지 않고 본다고…? 앞쪽에서 버퍼링 시간 벌려고.

윈도우 미디어 플레이어는 놀랍게도 tcp, udp, http… 등 중에 선택할 수 있다. 심지어 버퍼링 시간까지 설정할 수 있다. 즉 tcp는 어플과 매우 관련이 깊은.

BOOTPs,c : 하웨에서 부트스트랩 플을 갖고 오는 것이 아니고, 어딘가에서 OS랑 소웨를 그 때마다 가지고 오는 것. 공장에서 매일 아침마다 이렇게 하는 방식에 쓰인다.

19: UDP 프레임 포맷. 나중에 사진 한 번 보기는 하기. 체크섬: 에러가 있는지 없는지…

22: 그냥 메시지가 오고 처리하는 방식으로 통신 플을 하면 죽음. 24처럼 큐를 써야 한다

UDP가 폴링 방식으로 보내고, 클라이언트가 필요할 때 갖고 가는.

23: 어플에 점점 가까워지고 있기 때문에 서버와 클라이언트 중 서버가 먼저 동작을 해야 한다. 이게 전송 계층의 기본 규칙.

25: FTP는 파일을 보내는 것. 이 컴 간에는 절대로 에러가 날 일이 없다. 하면 UDP가 엄청난 속도 뽑아낼 수 있.

멀티 캐스트는 내가 보내면 n명 이상이 수신하는… TCP를 쓰면 오버헤드가 너무 크다… 라우터끼리 정보를 주고받으면… 라우팅 인포메이션 프로토콜

통신을 하면 두 가지 타입으로 존재한다. 컨트롤, 매니지먼트, 트래픽 이 세 개 부서로 통신 소웨는 구분된다. 부서도 이렇게 구분된다. 네트워크가 그렇게 잘 동작하는지 검사하는 것이 매니지먼트.

 

OSI 7계층은 상위 계층이 하위 계층 중 자기가 선택해서 쓸 수 있음.

컴퓨터 안에 원래 30개의 기능이 있다고 하면, 요즘은 하나의 컴 당 이 중 한 개의 function만 돌아가게 하는. 이게 육중한 서버에서 벗어난 것. 이것을 최초로 한 것이 아마존.

함수 하나의 기능이 한 번 호출하거나 전송할 때마다 돈을 번다. 이런 식으로 큰 컴을 짠 게 아니고, 이런 서버의 기능을 하나 하나 나눠서 사용하는 것이 아마존.

람다 프로그래밍은 비슷. 서버리스/마이크로서비스 컨셉은 이렇게 등장한 것.

네트워크를 가로지르는 프로그램을 많이 해보면 도움이 될 것이다.

29: 이젠 스트림의 바이트. Tcp는 두 플 간에 ‘바이트’를 보낸다.

30: 버퍼는 에러 검출용으로 가지고 있고. 오버플로는 피할 수 없기 때문에 버퍼가 다 찼을 때 맨 앞의 것을 잡아먹기 가장 적합한 구조가 원형 버퍼라서 이렇게 하는 거라고 한다

31: 동일한 패킷에 실려 가는 number of bytes. 일정 단위로 메시지 형태를 만든다. 메시지를 보내긴 하는데, 메시지 별로 관심 없고 다 바이트라는 점이 중요.

33: TCP는 하프 두플렉스도 가능. 뒤에 나올 것

34: 아주 헷갈리고 시험에 내기 좋은 녀석. 이제부터.

데이터링크 계층에서 쓰기 좋은 것. Segment의 넘버는 그 세그먼트가 실어 나르는 첫번쨰 바이트의 시퀀스 넘버이다. 첫번째가 갔을 때 8000으로 보낸 경우, 이 스트림에서 보내는 바이트의 첫번째 바이트의 시퀀스 넘버가… 8000인 것. 그렇다면 두번째 스트림의 번호는 9000인 것.

이걸 그림 그려서 설명할 줄 알아야.

씨플플의 스트림이 이 스트림이라고 한다.

이걸 다 포인터로 하기 떄문에 위에서 아래로 올라갈 때 제로 카피라고 하였다.

이젠 ack가 다음에 받을 스트림의 첫번쨰 바이트 시퀀스 넘버를 요청하게 된다.

38: 데이터 링크의 윈도우 사이즈. 저 빨간색 알파벳 6개는 각각 1비트다. 세팅 안되어 있으면(즉, 0) 핀을 끈 것. 1을 넣으면 그 기능 요청.

39: SYN이 제일 중요한데 이는 연결 요청을 의미한다. FIN = 피날레. ACK=1은 이걸 보내고 있딴 뜻. Reset은 뭔가 엉킨 것 같을 때 다시 새로운 맘으로 데이터를 주고받으려 할 때 1

42: 지금 8000번째 시퀀스 번호를 보냈으니 다음에 8001을 보내줘. 이에 대해 이렇게 하나 늘어난 번호인 8001이 된 건 아무 의미가 없다. 0으로 시작한 것이 아닌 그 랜덤 넘버를 최초 연결할 때 쓰는 번호가 8000이라는 점. 이니셜 시퀀스 넘버가 15000? 어쨌든 0부터 시작하지 않고 랜덤 넘버를 하려는 것. 이유는 보안의 이유. 항상 0으로 시작하면 다 걸리니까.

43: s비트를 퍼부으면 그만큼 tcp가 여러 개 만들어짐. 이게 syn flooding attack. 이렇게 의미 없이 오는 메시지들은 당연히 죽여야.

44: 15000까지 받았으니 15001부터 보내주세요. 이런 의미

클라이언트는 17000까지 잘 받았으니 17001부터 주세요 하는. 리시브 윈도우 당연히 있고. Selective repeat를 tcp에 적용해서 이해하면 됨

45: 기다리지 말고 당장 쏴. 하는 것. 통신 속도가 느린 하드에 뭘 저장하려 할 때, 하드가 매우 느리므로 통째로 블록을 주고 저장하라고 하고… 하는 방식이 필요. 통신도 비슷하게 통신 속도보다는 이렇게 꽉 차게 되면 이걸 다 보내야 한다. 메시지가 어느 정도 찰 때까진 안 보내다가, 지금 당장 보내야 할 때. 요 개념. 받는 쪽이 즉각 처리해라고 명령하는 것이 urgent. 그러나, 이걸 사용한 사례가 지금까지 한 번도 없었다. 보통 tcp를 잘 안쓰기 때문이라고 한다.

46: 이제 연결 해제에 대해 배우자. 피날레를 선언했을 때, f를 세팅하고 보내면 ~방향으로 보내는 것이 끝나는 것(녹음 더 들어볼 것!)

47: 아니 나는 아직 안 끝났어 할말 더 있어. 하는 것이 요 페이지 개념

48: 100을 보낸 담에 수신 버퍼 만들어짐. 101부터 900까지 받을 준비되어 있음. 수신 버퍼 사이즈로 800을 보낸다.

49: 상대방이 보냈다고 해서 바로 대답하지 않고, 타이머가 다 되고 나면 보낸다. 보통의 TCP는 바로바로 ack를 보내지 않는다. 이유? 통신의 속도는 패킷 퍼 sec인데… 받자마자 바로 ack를 보내면 뭐 하다가 죽는다. 즉 일정 시간동안 받은 것을 세다가 한 번에 모아서 ack를 보내준다. 그러나, 저속 링크 저사양에선 이렇게 동작했지만 이제는 아니다. 이게 일반 동작이지만.

이런 게 다시 TCP를 버리고 새로 만들게 된 계기.

50: 타이머 다 되고 ack를 받으면 송신단 버퍼의 데이터 지운다. 정확하게 selected repeat. 그렴 타이머 터지는 것 땜에 지연이 너무 큰데?

51: 이거 개선 버전. Ack가 끊임없이 생김. Delayed ack를 끔. 그러면 통신단에선 타이머 터진 것과 상관없이 바로 재전송을 한다. Tcp는 계량 요구가 있었고, … 빨리 재전송을 합시다. 하는… 회사나 프로젝트를 할 때 이 TCP는 어떤 버전이지?... TCP는 옵션도 많고 종류 다양하므로 이런 거 잘 알아두면 좋다

53: 타이머 터지면 달라고 하는 수밖에

TCP의 헤더를 기반으로 설명하라. 하는 문제 꼭 나온다. 단, 1번 2번 메시지 이렇게 하면 가차없이 틀린다. 그런데, 지금까지 혼잡 컨트롤이 등장한 적이 없음. 그러나, 혼잡이 있는지 알 수가 없다. 혼잡 없애달라고 요구하는 것도 없다. 그래서 지금 flow control하는 애는… 에러가 나거나 너무 오랜 시간이 지나서 ack가 오거나… 하면 에러가 날 때…. 우리가 쓰는 네트워크가 문제가 있구나 하고 생각한다. 혼잡기간이 에러에 의해 유추되면… 이제부터 나오는 규칙을 써야. 54,55.

54: 시작을 천천히. 본인이 들어갔을 때는 상대 컨트롤 플로우에 추가적으로 상대 리시브 윈도우가 충분하더라도 내가 처음 tcp 연결을 해서 보내는 시점이라면 윈도우가 마치 하나인 것처럼 해야 한다. 이걸 혼잡 윈도우라고 한다. Round Trip Time(갔다가 오는 round의 시간). 하나 받고 나면 그 다음엔 연이어 2개를 보낼 수 있다. 즉 조심스럽게 시작해보는 것이다. 이런 식으로 점점 2배씩 보낸다. 상대 리시브 윈도우에 여유가 있음에도 불구하고 조금씩 보내보므로써 조심스럽게 시작하는 행위를 말함

55: 하나씩 서서히 늘게 하여 주는

56: 4까지는 슬로우 스타트를 해보는. 잘 되기 시작하면 1씩 증가하는 2ㅓㅂㄴ쨰 방법으로 가고. 3duplication이 생겼다는 것은 에러가 생겼다는 것. 에러가 났을 때의 congestion은…

57: 3dup은 간헐적으로 하나가 벌어진, 일시적 에러일 수 있다. 그럼 그 특징은, 보통 네트워크는 그걸 다 계산을 해봐서, 트래픽을 줄이도록 계싼되어 있는데 뭐 어떻?...

58: TCP는 톱니바퀴 모양의 전송 속도를 갖게 된다

르노 버전에서 다음 개선 포인트는 어디가 되어야 하는가? 여기서 개선이 안되면? 내가 직접 짠다. 이게 전공자와 비전공자의 기준이 된다는 점!

저런 식으로 전송 속도가 좌지우지될 때 예측할 수 있는 문제는 무엇인가?

실제로 회사에서 많이 겪는 문제라고 한다. 절대 시간 안에 가야하는 서비스는 안갈 수도 있다. Accuracy가 맞아 떨어져야 하는 경우에는 tcp가 안된다. TCP는 네트워크를 죽이지 않으면서 전송하려고 했으니, 전송의 품질 개념이 없다. 마치 이더넷 같은. 이거 반드시 이해해야 한다. 요즘 통신 추이는 http로 많이 하는데, 이것도 결국 tcp를 기반으로 하고 있다. 즉, 문제는 tcp에서 발생하고 있으므로 이 문제를 개선해야 하는 상황인 것. 구글은 tcp를 안 넣고 udp를 넣는다. 따라서 첫번째 문제점은 최고/최저점… 흠… 누군가는 둘 중 어디에 있는. 그렇다면 58쪽을 유지하면서 성능을 올릴 수 있는 방법은? CPU마다 TCP 스트림? 윈도우?를 배치하자 TCP 스트림이 반드시 하나일 필요 없으니 코어마다 놔두고, 파일을 4개로 쪼개면 된다. 이를 통계적 다중화라고 한다. 이게 누적됐을 땐 잔잔하게 쌓인다. 클라이언트 서버를 올리는 방식은 TCP 개수를 늘린다. 방금 얘기한 방식은 멀티 코어, 멀티 프로세스를 이야기함. 파일 전송 프로그램을 키면, 대부분 서버를 2개 이상 만들고 ?하는 경우가…

그러면 받는 속도가 n분의1로 줄어든다. 이게 토렌트의 원리?... A와 B사이 스트림 개수를 여러 개 만든다…. 기초적이면서도 많이 활용하는 기법 중 하나.

스포티파이의 가장 큰 장점은, 음원도 버퍼링이 원래 필요하고, 스트리밍을 한 번 하면 캐싱해서 나중부터는 빨라지는 것임. 얘는 누르자마자 바로 나오는데, 걔네끼리 피어 투 피어를 구축하는데,,, 일정 시간이 지나면 스트리밍을 시작….???????

지금은 전송 속도를 올린 것인데, 다른 속도를 올리면….

TCP의 리시브 윈도우 디폴트는 64KB라고 한다. 그래서 리시브 윈도우 사이즈를 키우는 방법도 있다. 안드로이드는 3??~512. 너무 커지면 타이머가 커지고 재전송/복구 기능이 복잡해진다.

따라서 수신 버퍼 사이즈가 늘어나는 것도 전송 속도 늘어나는 방법 중 하나.

TCP연결을 하는 서버 시간은 언제인가? - sin오퍼레이션… 일상에서. TCP연결 설정은 웹과 웹 브라우저 사이에… 내가 네이버 닷컴에 연결하는… 경우는 내가 네이버 닷컴이라고 주소창에 쳤을 때… 로딩 속도가 왜 느린가… 서버가 암만 빨리 응답을 해도, 네이버를 딱 눌렀을 때 처음 전송하는 데이터는 매우 적잖아. 그래서 시작 시간의 반응 속도는 느릴 수밖에 없음. 즉, 반응 속도가 느린 것이 아니고, TCP 때문에 느린 것. 결국, 방법은 소스코드에 들어가서 슬로우 스타트를 안하도록 바꿔야 한다. 결국 혼잡을 피하려 했는데 risk를 또 감수해야 하는… 결국 서버와 네트워크 부서는 서로 우리는 이 정도는 처음에 받을 수 있어. 이렇게 혼잡 윈도우 사이즈를 미리 정해야 한다는 점.

시작 시간이 너무 느리다. 속도의 fluctuation이 넘 심하다.. 하는 문제가 있고.

넘버 시나리오는 네이버 웹 브라우저 요청 시작의 요청 끝난 직후에 일어난다. 일반적인 http는 화면을 갖고 오기 위해 연결. 이거 끝남 연결 끊음. 그러고 나서 연결 해제해버렸다. 그럼 네이버 입장서 아쉬운 것은?... 광고 보낸 횟수. 끊는 바람에 더 이상 보낼 수 없는 상황. 즉 한 번 밖에 못함. 이걸 늘리려면? … 이게 실제로 구글이나 네이버에서 쓰는 방법. 연결 요청은 항상 사용자가 해야 한다. 허락없이 사용자에게 데이터를 보내면 안되기 때문. 그래서 다양한 방법이 등장하는데, 기술인경우도 있고 아닌 경우도 있음. 네이버는 실검이라던가 여러 개의 단추를 만들어서, 직접 광고를 보게 유도를 한다. 이를테면, 실검 검색 결과를 새로 고침해서 다시보게하는 경우. 그 때마다 광고가 달라져도 그건 니가 한 것이므로… 합법.

그러면 크롬 브라우저에서 주소창과 검색 결과 기능을 합쳐 놓은 이유는 뭘까? 뭘 하는 것이고 왜 하는 것인가? 네트워크 레이어의 기능과 연관되어 있는 것. 물론 효율성의 의미도 있긴 하다. 그런데, 이 주소를 기계가 이해하는 IP어드레스로 바꾸는 과정, 도메인 네임 서버가 하는데,… 웹 브라우저 입장에선 내가 하는 게 아닌데, 나는 니가 요청해서 하는 건데… 왜 나한테 느리다고 해?- 를 방지. 기계들에 가서 미리 DNS 주소를 미리 로드해놓고 연결할 설정을 미리 해두면, 속도가 훨 더 빨라진다. 초기 반응속도가 가장 중요하다는 것이 웹의 불문율이다. 이동통신을 할 땐 과금 때문에 허락없이 이걸 하게 하는 것이 불법이다. 이런 식으로 속도를 올리기 위해 굉장히 많은 요소들을 넣어둠.

또, 비싼/저렴한 휴대폰에 대해. 대동소이한 것인 카메라의 기능. 운체의 기능도 비슷. CPU 퍼포먼스만 좀 다르다. 실제로 CPU도착해서 화면에 보이기까지의 시간도 어마어마하게 차지하는데 이 시간이 느리면 사용자가 불편할 것. 따라서 폰의 소웨가 어케 되어 있냐에 따라…

그럼 애초에 이렇게 문제가 많은 tcp를 쓰지말자고 한다면, QUIC 프로토콜. 이게 크로뮴에서 쓰는 것. http를 udp 위에 올린 것. 그 이유는 데이터 전송 및 초기 반응 속도 때문에 해야 하는 것. 물론 대신 에러 검출 복구 기능은 빠져있는. 이게 크롬 브라우저 안에 들어가 있는데. 이것의 도입이 최근 굉장히 빠르다. 데이터 센터 밖을 나가게 되면 사용하지 않길 권장한다고 써있.

 

요즘은 대용량 처리를 위해 C++을. C++은 대학을 나와도 이해하기 어려울 정도. 이젠 언어에 대한 진입 장벽은 없지만, 다른 진입장벽은 어마어마하다. 이를테면, 새로운 기술에 대한 책은 없다. 깃허브 가서 오픈소스를 보거나 커뮤를 가지 않으면 자료가 없다. 특히 로컬 언어 자료는 더더더더욱 없다. 따라서 이런 것을 설치할 때의 문제점은… 결국 오픈소스… VS 는 자료도 없고 오픈소스… 대부분의 신기술은 다 리눅스 위에서만 되고.. 결국 오픈소스이자 리눅스 기반이라서,,, 이 분야로 가서 능력자가 되려면, 알아서 열심히 스스로 자료 뒤져가며… 하는 이 진입 장벽이 매우…. 커짐.

그러면 왜 전공자보다 비전공자를 선호하는지,

왜 신입 안뽑고 경력직을 뽑으려는 건지: 제반 지식이 필요한데, 이걸 우직하게 거쳐서 배운 사람은 언어 배우는데 엄청 빨리 할 수 있지만 뭐….

그리고 지금까지 다룬 적 없는 게 1:n 통신이다. 그러나 우리가 아는 것중에 이 통신이 엄청 많은데. 전통적인 4계층에서는 이것이 불가능하다. 그러나 요즘 기술로는 아주 쉽다.