WEB에는 대 프로토콜 HTTP가 있다. HTTP에 대해 간략히 복습하자면 HTTP는 비연결 지향 프로토콜이다. 클라이언트의 요청(Request)이 서버로 전송되고 응답(Response)이 완료되면 연결이 즉시 종료된다. 이러한 특성 때문에 요청 간의 상태가 유지되지 않으며, 한 번 전송된 메시지는 서버나 클라이언트 어느 쪽에서도 자동으로 저장되지 않는다. 하지만 모든 메시지가 즉시 연결이 종료되면 안될 수 있다. 예를 들어, 클라이언트가 보낸 메시지를 지속적으로 조회하거나,서버가 실시간으로 상태 변화를 전달해야 하는 상황이라면HTTP의 비연결·비상태 특성만으로는 한계가 발생한다. 이러한 문제를 해결하기 위해 다양한 방식이 등장했다.Long Polling, Server-Sent Events(SSE), 그..
1주차에 UDP TCP를 학습을 하고 2주차에는 HTTP를 학습하였습니다. OSI로 따지든 TCP/IP기준으로 따지든 둘다 데이터라는 것을 통신하게 되어집니다. 당연한 얘기겠지만, 계층이 올라가면서 이 안에서 동작하는 전기 신호의 이름은 변경이 되었습니다. 어찌보면 그냥 신호일뿐인데 어째서 이것들을 나누었을까요? 이건 제 생각인데 계층 마다 분리를 하고 싶었던게 아닌가 싶습니다. 이거는 이러니까 이거지.. 개인적으로 "장비" 입장에서는 신호를 나타나내는 용어가 그렇게 중요할까요? 아마 사람에게 중요한 일일 겁니다. 그래야 구분짓기 쉬우니까 그 당시 인간들은 이런 행위를 굉장히 즐긴거 같습니다. 계층 나누고 그것을 부리는 명칭을 달리하는 것말이죠. 얘네를 왜 학습해야 하지?가만 생각해보면 이것들을 왜 알아..
오픈 채팅방에커리어 상담글이 올라왔다. 현재 나는 4년째 백엔드 개발자고 8개월째 이직 준비중에 있다. 또한 도메인변경을 원했기 때문에 커리어 상담을 신청하게 되었다. 어찌 저찌 신청서를 제출하고 기달렸다. 10월 26일 일요일 7시에 상담해준다는 연락을 메일로 받았다. 사실 토욜이었는데 취소되었고 일욜로 바뀌었지만 난 못봤다. 상담 시작간단하게 자기소개를 하고 어떤것을 지금 중점적으로 해야 하는지 설명해주셨다. 일단 나는 이커머스로 도메인 변경을 원했는데사실 이커머스에서 어떤일을 하는지 왜 그 도메인을 원하는지에 대해 구체적으로 고민하지 않았던거 같다. 단순히 생각했을때 고객들과 가장 밀접한 도메인이라고 생각만 했지 구체적으로 생각하지는 않은거 같다.기술같은 경우도 머릿속에 아른거리는 기술들만 있지 실..
이전 장에서 예고한것처럼 쿠키랑 세션에 대해 알아봅시다. HTTP에서 TLS이 추가되어서 보안이 증가된 형태인거는 이제 이해했는데 그렇다면, 인증쪽은 어떻게 처리를 해야 할까요? 아니 애초에 이게 왜 필요한건지 이해할 필요가 있을거 같습니다. 웹이나 앱등등 사용자를 등록하게 되어집니다. 등록을 하게 되면 로그인이라는걸 하게 되는데 그런 다음 어떻게 해야 할까? 쿠키나 세션 하물며 JWT토큰 조차 없다고 생각해보자 이거는 그냥 데이터에 불과할겁니다.. 그걸 통해 뭔가 액션을 취할 수 는 있겠는데 그걸 계속 유지를 시킬 수는 없습니다. 왜냐하면 HTTP는 알다시피 Stateless 비연결성 프로토콜입니다. 즉, 한 번 요청하고 응답이 끝나면 그 연결에 대한 기억은 완전히 사라집니다. 여기서 어라? HTTP는..
지난번에 TCP와 UDP를 학습하였습니다. 이제 이것을 발전시킨 기술 하나를 살펴볼 건데요. 그것은 바로 HTTP입니다.HTTP가 웹을 위한 프로토콜로 잘 알려져 있긴 하지만 HTTP에 대해 잘 알지 못하고 있습니다. 인터넷에 HTTP를 검색하면 많은 정보들이 나오긴 하지만 생각만큼 잘 와닿지 않았습니다. 1960년대에 HTTP라는 기술에 대한 설계가 시작이 되었고, 팀 버너스 리를 필투로 1989년에 HTTP가 개발이 되었다고 합니다. 어떻게 보면 중요한 내용일 수도 있겠지만, 생각해 보면 지금 말하고 있는 사실과 HTTP의 연관성을 짓지 못하는 경우가 많은 거 같습니다. 이러한 이유가 발생한 이유가 뭘까요? 단순히 암기를 하려고 했던 게 아닐까요? 이번에 제대로 HTTP를 빠개봅시다.HTTP는 어디에..
* 초안입니다. 배경TCP는 뭐고 UDP는 뭘까우리가 알기로는 TCP는 느리지만 신뢰성이 좋다고 하고, 그리고 UDP는 느리지만 신뢰성이 좋지 않는다고 한다.왜 그럴까?어떤 이유 때문에 TCP는 느릴까?TCP는 UDP보다 하는일이 굉장히 많다. 예를 들어, 신뢰성과 안정성을 보장하기 위해서는 기능이 많이 필요하다.다음은 TCP,UDP가 하는일은 다음과 같다고 한다.📡 TCP (이중 확인, 안정형)[연결 준비] → 3-way handshake[데이터 전송] → 패킷 전송 후 ACK 수신[손실 발생] → 재전송[혼잡 발생] → 전송 속도 감소[종료] → 4-way handshake로 세션 정리➡️ 신뢰성 높음, 하지만 왕복 지연(RTT)마다 제어 수행 → 상대적으로 느림⚡ UDP (던지고 잊기, 불안정형)..
학습 키워드Unit Test / Integration Test / E2E Test테스트 Pyramid테스트 커버리지 vs 유의미한 테스트유닛테스트라는건 뭘까?서비스단에서? 컨트롤단에서? 음 아무래도 상관없으려나유닛테스트는 단위테스트라고 하며그림을 보면 알수 있듯이 단위 테스트는 테스트 피라미드 바닥에 존재하며 굉장히 많은 수 가 있다는 것을 알 수 있습니다.이는 간단하게 작성이 되어진다는 뜻이 되어집니다.이전 포스트에서도 말했었지만 테스트코드는 굉장히 중요합니다. 그렇다는 이야기는 e2e를 하든 통합을 하든 유닛을 하든작성을 하는것이 좋습니다. 여기서 중요한 사실은 유닛테스트가 양이 제일 많다는 것입니다. 그렇다는건 유닛테스트를 중점으로 테스트코드를 짜야 된다는 뜻이 됩니다.그리고 그림에서 보면 알 수 ..
10주간을 되돌아 보며10주동안 이커머스에서 발생할 수 있는 여러가지를 학습을 하였다. 1주차로 워밍업을 하고 2~10주차에서 본격적으로 설계를 진행하였다.사실 어떤것을 학습을 하였는지 구체적으로 기억은 잘 나지 않는다. 일단 기억이 나는데로 얘기를 해보자면1주차1주차때 테스트 코드를 작성하였다. 테스트 코드의 중요성은 잘 알고 있었지만 뭐랄까 막연한 두려움이 있었다. 어떻게 작성하면 될까...@DisplayName("두개에서 한개를 제거하는 경우, 주문 상품의 갯수는 한 개를 리턴합니다.")@Testvoid returnOrderItemSizeIs1_whenRemove1Product() { //given OrderItemModel orderItem1 = OrderItemModel.builder() ..
랭킹이라가는건 뭘까 단순한 줄 세우기인가어떤 기술을 사용하면 효율적일까?사실 랭킹은 생각보다 쉽다.정확히 말하면 쉽게 생각할 수록 쉽게 만들 수 있는거라 생각한다.랭킹은 RDB로 하는것이 좋을까? 아니면 nosql로 하는것이 좋을까?정답은 없다고 생각한다.어떤 기술을 사용해야 한다는것은 없다고 생각한다.nosql중에는 레디스를 활용해서 데이터를 저장한다.결국 RDB랑 레디스와 비교를 하는것이 중요하다고 생각이 든다.어떤것이 더 랭킹 시스템에 어울릴수 있는지 생각할 수 있을거 같다.나는 랭킹 시스템을 레디스로 만들었는데 그 이유는 낮은 오버헤드와 읽기 성능이 좋다는 것을 높게 평가하였다.레디스는 다양한 자료구조를 지원하는데 그 중에서도 Zset을 이용하게 되었다. Zset은 레디스가 가지고 있는 낮은 오버..
배경카프카에서 수신한 정보를 토대로 계산하여 랭킹을 산출하고 있었다. 지금 보여주고 있는것이 사용자가 원하는 랭킹일까?잘 모르겠다. 실제로 운영이 되지 않는점도 크다고 생각한다. 만약 실제로 운영 된다면, 사용자들이 자주 들어오는 시간을 측정해서 가중치를 반영할 수도 있다 생각한다. 실제로 운영되는 환경이 아니기 때문에 부하테스트를 돌려서 확인하는것이 최선이지 않나 싶다.랭킹 서비스를 만들기 위해서는 데이터를 저장을 해야 한다. 그래야 그걸 통해 정보를 보여줄 수 있기 때문이다. 그래서 최대한 예상을 해서 작성해보려구 한다.수신 장치현재 카프카를 통해 데이터를 수신하고 있다.각 토픽에 맞게 메시지를 전송하고 있다.@Component@RequiredArgsConstructorpublic class Prod..
