TCP/IP를 공부하던 중 TCP는 데이터 송수신의 순서를 보장한다는 글을 읽었다. 학교에서 네트워크 수업을 들을 때 분명히 패킷이 분할되고 재조립하는 과정을 거친다고 했었다. 송신측에서 전달한 데이터는 패킷으로 분할되고, 패킷은 라우터를 거치며 수신측으로 보내지기 때문에 수신측에 패킷이 도착하는 순서가 보장되지 않는다는 생각이 문득 들었다. 패킷이 수신측에 순서대로 도착하지 않는데 TCP는 왜 순서를 보장하지? 라는 의문이 생겨서 관련 내용을 쭉 찾아봤는데, 추상적으로 설명해놓은 글이 많아 정리하려고 한다. TCP/IP 네트워크 통신을 위한 과정을 분류하는 모델로 OSI 7 계층이라는 표준이 존재한다. 우리가 HTTP 통신을 하기 위해 주로 사용하는 TCP/IP 프로토콜을 OSI 7 계층에 맞추어 추상..
데이터 송신 수신 동작의 개요 DNS 서버를 통해 IP 주소를 조사했으면 액세스 대상 웹 서버에 메시지를 송신하도록 OS 내부에 있는 프로토콜 스택에 의뢰한다. 디지털 데이터를 송, 수신 하는 동작은 브라우저뿐만 아니라 네트워크를 이용하는 애플리케이션 전체에 공통이므로 이 동작은 웹에 한정되지 않고 모든 네트워크 애플리케이션에 해당된다. 여기에서도 DNS 서버에 IP 주소를 조회할 때와 같이 Socket 라이브러리에 들어있는 메서드들을 이용하는데, IP 주소를 조회할 때 처럼 하나씩 호출하고 끝나지는 않는다. 많은 메서드들을 결정된 순번대로 호출해야 하므로 복잡한 과정을 거친다. 즉, OS 내부의 프로토콜 스택에 메시지 송신을 의뢰할 때는 Socket 라이브러리 프로그램 메서드를 결정된 순서대로 호출한다..
문제상황 컨트롤러 테스트를 작성하던 중 Mock 객체를 사용해 서비스 로직 반환 값을 지정했는데도 불구하고 null 값이 반환되는 상황이 발생했다. @Test @DisplayName("가게를 정상적으로 생성한다.") void createSuccess() throws Exception { StoreRequest storeRequest = createRequest(); StoreResponse storeResponse = createResponse(); when(storeService.save(storeRequest)).thenReturn(storeResponse); ResultActions resultActions = mockMvc.perform(post("/api/v1/stores") .with(csrf..
DNS 서버의 기본 동작 DNS 서버의 기본 동작은 클라이언트에서 조회 메시지를 받고 조회 내용에 응답하는 형태로 정보를 응답하는 일이다. 클라이언트의 조회 메시지에는 다음의 세 가지 정보가 포함된다. 1. 이름 서버나 메일 전송 목적지와 같은 이름이다. gray1234@google.com이라고 하면 google.com을 의미한다. 2. 클래스 클래스는 항상 인터넷을 나타내는 'IN' 값을 사용한다. 3. 타입 이름에 어떤 타입의 정보가 지원되는지 나타낸다. 예를 들어 타입이 A(주소)이면 이름에 IP 주소가 지원되는 것을 나타낸다. 예를 들어 이름이 www.lab.google.com인 서버의 IP 주소를 조사할 때 클라이언트는 이름 = www.lab.google.com , 클래스 = IN, 타입 = A..
IP 주소의 기본 HTTP 메시지를 만들면 이후에는 OS에 의뢰하여 액세스 대상의 웹 서버에게 송신한다. 앞서 설명한 것처럼 브라우저는 URL을 읽고 HTTP 메시지를 만들지만, 메시지를 네트워크에 송출하는 기능은 없으므로 운영체제에 네트워크에 송출하도록 위임한다. 이때 URL안에 쓰여있는 서버의 도메인 명에서 IP 주소를 획득해야 한다. IP 주소는 TCP/IP의 개념에 기초해서 만들어졌고, TCP/IP는 서브넷이라는 작은 네트워크를 라우터로 접속하여 전체 네트워크가 만들어진다고 생각할 수 있다. 쉽게 생각하면 하나의 허브에 여러 컴퓨터가 접속되었다는 것이다. IP 주소는 OO동 OO번지 라는 형태로 네트워크 주소를 할당받는데, 여기서 동에 해당하는 번호가 서브넷에 할당되고, 번지에 해당하는 호스트 번..
1. 웹 브라우저 여행은 URL 입력부터 시작한다 URL은 http 뿐만 아니라 ftp, file, mailto로 시작하는 것 등 여러 가지가 있다. 웹 서버에 접근할 때는 http, FTP 서버에 접근할 때는 ftp 라는 식으로 여러 종류의 URL이 준비되어 있다. 모든 URL에는 공통점이 있는데, 맨 앞에 있는 문자열에서 엑세스하는 방법을 나타낸다는 것이다. * HTTP 프로토콜로 웹 서버에 엑세스하는 경우 http://user:password@www.cyber.co.kr:80/dir/file1.htm * FTP 프로토콜로 파일을 다운로드하거나 업로드하는 경우 ftp://user:password@ftp.cyber.co.kr:21/dir/file1.htm * 클라이언트 PC 자체의 파일에서 데이터를 읽..
레벨 1의 두 번째 미션은 사다리 게임입니다. 이번 미션부터는 TDD로 진행해야 하는 요구사항이 추가되었습니다. TDD는 Test Driven Development의 줄임말로 테스트 주도 개발이라는 뜻을 가지고 있습니다. 이번 미션에서는 사다리 구조를 잡고 생성하는 것부터 사다리 게임을 실행하는 로직까지 전부 TDD로 진행해야 했습니다. TDD를 하는 이유 - 디버깅 시간을 줄여준다. - 동작하는 문서 역할을 한다. - 변화에 대한 두려움을 줄여준다. TDD 원칙 원칙 1 - 실패하는 단위 테스트를 작성할 때까지 프로덕션 코드(production code)를 작성하지 않는다. 원칙 2 - 컴파일은 실패하지 않으면서 실행이 실패하는 정도로만 단위 테스트를 작성한다. 원칙 3 - 현재 실패하는 테스트를 통과..
개발 배경 리눅스 컨테이너는 런타임 환경에서 애플리케이션을 패키지화하고 분리하는 기술입니다. 실행에 필요한 모든 파일이 호스트 시스템과 분리되어 동작하기 때문에 컨테이너 환경에서 동작하는 프로레스는 이식과 관리가 쉽습니다. 하지만 컨테이너의 리소스가 호스트와 분리되었다고 해도 실제 스토리지에 저장되는 데이터들은 격리되지 않습니다. 즉, 하나의 스토리지를 여러 컨테이너가 공유해서 사용하고 여러 컨테이너가 동시에 한 스토리지에 접근하는 경우 I/O 간섭이 발생합니다. 만약 이러한 데이터들 사이에 격리(컨테이너 수준의 격리)가 이루어진다면 각 컨테이너들이 저장 장치에 접근할 때 I/O 간섭이 발생하지 않기에 빠르고 효율적인 처리가 가능해질 것입니다. 기존 문제점 현재 사용되는 Block Interface SS..
레벨 인터뷰란? 각 레벨에서 학습한 내용을 인터뷰 형식으로 진행하는 말하기 활동이다. 이번주 수요일(3.29)에 레벨 1을 마무리하는 인터뷰를 진행했다. 코수타에서 레벨 인터뷰 안내를 받았을 때는 편하게 참여해도 된다고 하셔서 별 생각없이 있었는데, 막상 준비해보니 편하게 임할..수가 없었다 ! 진행 방식은 6~7명의 한 그룹에서 인터뷰이, 인터뷰어, 옵저버의 역할을 담당해서 진행했다. 한 인터뷰이당 30분동안 진행하며, 20분은 인터뷰 나머지 10분은 피드백을 받는 시간으로 진행했다. 각 그룹마다 한 명의 담당 코치가 배정되는데 우리 그룹에는 브라운과 함께 했다. 조원들로는 애쉬, 코코닥, 도기, 땡칠, 아코, 두둠과 함께였고, 한 번씩 이야기를 나눠봤던 크루들이라 비교적 편안했다. 레벨 인터뷰를 진행..
표준 예외란? 자바 API에서 제공하는 예외를 말한다. 대표적으로 IllegalArgumentException, IllegalStateException 등이 있다. 표준 예외를 사용하면 가독성이 높아지고, 사용하기 쉬워진다. 다른 프로그래머들에게 이미 익숙해진 규약을 그대로 따르기 때문이다. 표준 예외를 사용하면, 직접 구현하는 예외 클래스 개수가 적어진다. 따라서 메모리 사용량도 줄어들고, 클래스를 메모리에 적재하는 시간도 적게 걸린다. 대표적인 표준 예외 1. IllegalArgumentException 호출자가 인수로 부적절한 값을 넘길 때 던지는 예외이다. 예를 들어 Crew의 나이를 입력 할당하는 메서드에서 음수가 할당되는 경우이다. public void setAge(int age) { if (..
- Total
- Today
- Yesterday
- dm-zoned 코드분석
- 회고
- ZNS
- 네트워크
- 프로젝트
- 스프링MVC
- 파이썬
- 피움
- 알림기능개선기
- Spring
- dm-zoned
- 우테코
- 런칭 페스티벌
- java
- 피움 6주차 회고
- 스프링 부트
- 팀프로젝트
- 스프링 Logback
- 백준
- 스프링 프레임워크
- CI/CD
- 우테코 회고
- 알림개선기
- jpa
- ZNS SSD
- 8주차 회고
- 3차 데모데이
- 환경 별 로깅 전략 분리
- 2차 데모데이
- 5주차 회고
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |