Programming/Network


아주 다양한 오류들을 마주쳤다... = 내가 성장하는 과정잊지 않도록 기록하기 나의 현재 상황은 Nginx로 SSL 인증서는 받았고, 도커 이미지로 업로드하다가 HTTPS 적용이 어려워서 결국 Docker Container로 Nginx 서버와 Backend 서버를 함께 올리기로 함. 그리고 이를 위해 github에 올리고, 해당 소스를 EC2 인스턴스에서 받아 docker compose up 하기로 함.1. 첫번째 오류깃에서 pull 받고 빌드 해보는 과정에서 이러한 오류가 났다. RefrigBackendApplicationTests > contextLoads() FAILED java.lang.IllegalStateException at DefaultCacheAwareContextLoaderDel..


1. Docker 회원가입 및 설치 https://hub.docker.com/ Docker Hub Container Image Library | App ContainerizationIncrease your reach and adoption on Docker Hub With a Docker Verified Publisher subscription, you'll increase trust, boost discoverability, get exclusive data insights, and much more.hub.docker.com https://www.docker.com/products/docker-desktop/ Docker Desktop: The #1 Containerization Tool for D..


1. 캐시 기본 동작 1) 캐시가 없을 때- 데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 함.- 인터넷 네트워크는 매우 느리고 비싸다.- 브라우저 로딩 속도가 느리다.- 느린 사용자 경험 2) 캐시 적용- 캐시 가능 시간동안 네트워크를 사용하지 않아도 됨.- 비싼 네트워크 사용량을 줄일 수 있음.- 브라우저 로딩 속도가 매우 빠르다.- 빠른 사용자 경험>> 첫 번째 요청 시 캐시가 유효한 시간을 서버에서 응답으로 보내면 > 클라이언트에서 받아 브라우저 캐시에 저장>> 이후 새로 요청이 왔을 때 브라우저 캐시를 먼저 살피고 유효시간이 초과되지 않으면 캐시에서 조회할 수 있음.>> 만약 캐시 시간이 초과될 경우 다시 클라에서 서버로 요청을 보내고 다시 같은 형식의 응답을 보내주면..


1. HTTP 헤더 개요1) 용도HTTP 전송에 필요한 모든 부가정보ex) 메시지 바디의 내용, 메시지 바디의 크기, 압축, 인증, 요청 클라이언트, 서버 정보, 캐시 관리 정보표준 헤더가 너무 많음..필요시 임의의 헤더 추가도 가능하다. 2) RFC2616: 과거에는 HTTP 표준으로 RFC2616을 사용했다. 메시지 본문(message body)은 엔티티 본문(entity body)을 전달하는데 사용.엔티티 본문은 요청이나 응답에서 전달할 실제 데이터엔티티 헤더는 엔티티 본문의 데이터를 해석할 수 있는 정보 제공 (like 데이터 유형, 데이터 길이, 압축 정보 등) 3) RFC 7230 ~ 7235: 2014년에 등장하여 RFC2616은 폐기되었다. - 주요 변화 엔티티(Entity) -> 표현(..


1. 상태 코드 : 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능- 만약 모르는 상태 코드가 나타나면 (클라이언트가 인식할 수 없는 상태코드)? : 상위 상태코드로 해석해서 처리. 몇백대 상태코드인지를 확인하면 된다. 1) 1xx (Informational) : 요청이 수신되어 처리중 (거의 사용하지 않음)2) 2xx (Successful) : 요청 정상 처리 (클라이언트의 요청을 성공적으로 처리) - 200 OK : 요청 성공- 201 Created : 요청 성공해서 새로운 리소스가 생성됨.- 202 Accepted : 요청이 접수되었으나 처리가 완료되지 않음.배치 처리 같은 곳에서 사용 (ex. 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리함) - 204 No Content :..


1. 클라이언트에서 서버로 데이터 전송 1) 쿼리 파라미터를 통한 데이터 전송- GET - 주로 정렬 필터(검색어)2) 메시지 바디를 통한 데이터 전송- POST, PUT, PATCH - 회원가입, 상품 주문, 리소스 등록, 리소스 변경 1) 정적 데이터 조회- 이미지, 정적 텍스트 문서- 조회는 GET 사용- 정적 데이터는 일반적으로 쿼리 파라미터 없이 단순하게 조회 가능. 2) 동적 데이터 조회- 주로 검색, 게시판 목록에서 정렬 필터 (검색어) : 조회 조건을 줄여주는 필터, 조회 결과를 정렬하는 정렬 조건에 주로 사용- 조회는 GET 사용- 쿼리 파라미터 사용해서 데이터를 전달.3) HTML Form을 통한 데이터 전송: 회원 가입, 상품 주문, 데이터 변경- GET, POST만 지원.- HTTP..


1. HTTP API- URI 설계에서 가장 중요한 것은 리소스 식별 -> 리소스를 URI에 매핑.- 리소스와 행위를 분리한다. (리소스는 명사, 행위는 동사) -> 행위는 HTTP 메서드 ex.회원 목록 조회/members회원 조회/members/{id}회원 등록/members/{id}회원 수정/members/{id}회원 삭제/members/{id} 2. HTTP 메서드 1) 주요 메서드GET : 리소스 조회POST : 요청 데이터 처리, 주로 등록에 사용PUT : 리소스를 대체, 해당 리소스가 없으면 생성PATCH : 리소스 부분 변경DELETE : 리소스 삭제2) 기타 메서드HEAD : GET과 동일하지만 메시지 부분을 제외하고, 상태 줄과 헤더만 반환OPTIONS : 대상 리소스에 대한 통신 가..


1. HTTP (HyperText Transfer Protocol) : HTTP 메시지에 모든 것을 전송한다. (HTML, TEXT, IMAGE, 영상, 음성, 파일, JSON, XML...) HTTP 역사- HTTP/0.9 1991년 : GET 메서드만 지원, HTTP 헤더X- HTTP/1.0 1006년 : 메서드, 헤더 추가- HTTP/1.1 1997년 : 가장 많이 사용. 가장 중요한 버전 ! - RFC2068 (1997) -> RFC2616 (1999) -> RFC7230-7235 (2014) - HTTP/2 2015년 : 성능 개선- HTTP/3 진행중 : TCP 대신 UDP 사용, 성능 개선현재 HTTP/1.1 주로 사용하지만, HTTP/2, HTTP/3도 점점 증가하고 있다. 2. HT..


1. URI (Uniform Resource Identifier): URI는 로케이터(locator), 이름(name) 또는 둘 다 추가로 분류될 수 있다. - Uniform : 리소스 식별하는 통일된 방식- Resource : 자원. URI로 식별할 수 있는 모든 것 - Identifier : 다른 항목과 구분하는데 필요한 정보- URL : Locator. 리소스가 있는 위치를 지정- URN : Name. 리소스에 이름을 부여.- 위치는 변할 수 있지만, 이름은 변하지 않는다. - URN(이름)만으로 실제 리소스를 찾을 수 있는 방법이 보편화 되지 않았다. 그러므로 URL = URI로 생각하면 간단. A Uniform Resource Identifier (URI) is a compact sequenc..