한주가 끝나간다!!
이제 오늘 지나고 내일만 지나면 힘들면서 즐거웠던 부스트 캠프가 종료됩니다.
먼가 시원섭섭한 느낌이긴 한데 사실 끝나서 더 좋은쪽에 가깝습니다 ㅋㅋㅋㅋㅋ
이렇게 밤새가면서 코딩 해본건 고등학교때 게임을 만들 때 이후로 처음인것 같습니다.
아마 이렇게 열정적으로 코딩을 해볼 기회가 더 있을까 싶습니다.
지금까지 사실 성장하려고 말은 했지만 말만 했던것같습니다.
왜냐하면 몇년동안 말만 해온것보다 한달동안 직접 부딪혀 가며 배운게 더 많기 때문입니다.
네트워크 계층
개발자를 하려면 네트워크에 대한 지식은 필수로 있어야 된다고 생각해 왔습니다.
사실 잘 몰라도 코딩하는데 큰 지장은 없기에 귀찮다고 안해왔습니다.
그런데 이번에 소켓 통신을 구현하면서 그 생각을 다시 바꿨습니다.
네트워크는? 노드와 링크가 연결되있고 리소스를 공유하는 집합이라고 할 수 있습니다.
그리고 서로 다른 장비에서도 통신을 하기 위해 표준이 존재하는데요. 바로 OSI 7계층 모델과 TCP/IP 4계층 모델입니다.이 덕분에 다른 나라 혹은 기업과도 호환성 문제 없이 교류가 가능한겁니다.
그리고 두 계층은 아래와 같이 생겼습니다.
osi 계층이 tcp/ip 계층을 더 세분화한 느낌입니다.
TCP, UDP
TCP와 UDP는 Transport Layer의 프로토콜입니다.
TCP는 연결지향적이고 데이터의 도착을 보장합니다. 만약 실패시 재전송도 합니다.
UDP도 역시 Transport Layer의 프로토콜이며, 비연결지향이고 데이터의 도착을 보장하지 않습니다. 그리고 재전송도 요청하지 않고요
그래서 TCP는 전송속도가 느리고, UDP는 빠릅니다. UDP의 헤더 크기가 작은것도 한몫 합니다.
아래가 TCP 프로토콜의 헤더인데 딱 봐도 뭔가 많아보이는게 보입니다. 크기는 20바이트+@ 입니다.
아래가 UDP의 헤더인데 딱 봐도 아무것도 없어보입니다. 그래서 크기가 8바이트 고정입니다.
사실 크기 때문도 있지만 데이터를 보내는 방식 때문에 속도 차이가 나게됩니다.
TCP는 가상회선 패킷 교환 방식을 사용합니다.
연결되는 길 한개를 만들어놓고 패킷이 순서대로 전달되는겁니다. 그래서 도착 순서도 동일합니다.
데이터를 전달하기 전에 3웨이 핸드쉐이킹을 실시합니다. 그 후 모든 연결을 해제할 때는 4웨이 핸드쉐이킹으로 연결을 끊습니다.
근데 UDP는 데이터그램 패킷 교환방식을 사용합니다.
정해진 경로 없이 모든 패킷이 각자 수신 호스트로 보내집니다. 그래서 패킷의 출발, 도착 순서가 다를수도 있습니다. 핸드쉐이킹 과정이 없기에 요청을 받으면 그냥 바로 보내버립니다.
캡슐화, 비캡슐화
근데 데이터를 바로 보내는게 아니라 애플리케이션 계층에서 출발한 데이터는 캡슐화를 거쳐 링크 계층(물리)까지 내려옵니다.
이 과정을 캡슐화 한다고 합니다.
애플리케이션 계층에서 출발한 데이터에 각 계층의 헤더가 붙어 프레임 트레일러에 실려 전송됩니다.
그리고 받을때는 반대로 비 캡슐화 과정을 거쳐 헤더를 인식하가며 애플리케이션 계층까지 올라온 데이터를 사용자가 읽게됩니다.
소켓
소켓은 위의 tcp/ip 4계층에서 응용 프로그램과 전송계층 사이에 있는 인터페이스 입니다.
즉 응용 프로그램과 전송계층의 소통 창구라고 생각하면 될것같습니다.
통신을 통해 전달되는 모든 데이터 포맷은 5-tuple 이라는 규격에 맞추어 흐르게 됩니다.
- 프로토콜
- 호스트 IP 주소
- 호스트 port 번호
- 목적지 IP 주소
- 목적지 port 번호
소켓도 위 정보들이 있어야 정의가 됩니다.
즉, 다른 목적지의 정보와 내 정보가 들어있습니다.
그리고 중요한게 1개의 프로세스는 1개 이상의 소켓을 사용할 수 있는데 즉 수많은 호스트들과 통신이 가능합니다. 구별은 소켓번호로 식별합니다.
근데 소켓은 TCP/IP 표준이 아니라 네트워크 프로그래밍 인터페이스 입니다.
그래서 운영체제마다, 언어마다 소켓 API를 구현한 라이브러리가 다릅니다.
데코레이터
데코레이터란?
새 함수를 반환해서 전달된 함수 또는 메서드의 동작을 수정하는 함수라고 정의할 수 있습니다.
이번에 소켓으로 통신을 구현하는데 서버의 컨트롤러가 하는 역할이 너무 컸습니다.
거의 모든 역할을 다 맡아서 하도록 설계를 했었어요.
그래서 컨트롤러에게 맡겨진 임무를 분담해 주기 위해 자바 스프링의 @Controller 어노테이션을 생각해 봤습니다. 찾아보니까 js, ts에는 데코레이터가 있었습니다. 그런데 정식 기능은 아니고 곧 추가될 기능이긴 한데 사용할수는 있다고 합니다.
이 데코레이터를 사용해서 메소드가 평가되는 과정에 해당 메소드를 컨트롤러로 등록을 해줬습니다.
근데 이 때는 컨텍스트가 클래스 내부가 아니라 따로 바인딩 되는곳이 없었습니다.
그래서 만약 메소드 안에서 this를 사용한다면 해당 값을 찾을수 없다고 undifined를 뱉어냈습니다.
문제를 해결하기 위해 찾아보니 메소드를 static으로 선언하면 this가 알아서 바인딩 된다는 거였습니다. 아마 미리 메모리에 올라가 있어서 해당 컨텍스트를 식별할 수 있는것같습니다. 자세한건 더 찾아봐야 할것같습니다.
끗
이제 내일 일정만 소화하면 부스트캠프를 수료하게 됩니다.👏👏👏👏👏👏
고생한 나 자신을 위해 내일은 맛있는걸 먹을겁니다!! 치맥!!!!
정말 느낀점이 많은데 이건 내일이나 주말에 작성하려 합니다.
오늘도 저번에 이어서 작년의 나는 오늘 무었을 했는지 적으며 마치겠습니다.
8월 2일과 4일에 작성한 글이 있네요. 4일에는 두개나 작성했습니다!!
- 2022/08/02
- 글: https://velog.io/@song961003/React-%EB%AA%A8%EB%8B%AC-%EC%97%AC%EB%9F%AC%EA%B0%9C-%EB%9D%84%EC%9A%B0%EA%B8%B0
- 이때도 뭐 했는지 새록새록 기억이 나네요. 팀 프로젝트를 하고 있을 때 모달을 구현하려고 아둥바둥 하고 있었습니다. 이때는 별다른 특이사항 없이 그냥 기본적인 모달을 만들었습니다.
- 2022/08/04
- 글: https://velog.io/@song961003/useModal-%EB%AA%A8%EB%8B%AC-%EC%95%A0%EB%8B%88%EB%A9%94%EC%9D%B4%EC%85%98-%EC%A3%BC%EA%B8%B0
- 글: https://velog.io/@song961003/ToyProject-%EA%B0%80%EA%B3%84%EB%B6%80-2-%EB%AA%A8%EB%8B%AC-%EC%9B%94-%EC%84%A0%ED%83%9D
- 이제 만든 모달을 개발자 친화적으로 바꾸었습니다. 그렇게 useModal을 만들고 애니메이션도 넣을 수 있게 만들었습니다. 하지만 이 때는 실력이 부족해 리액트의 상태 사이클을 잘 이해하지 못해서 애니메이션 버그를 고치지 못해 나중에 고쳤습니다. 더 나중에는 해당 훅을 선언적으로 다시 작성하기도 했었네요.
