jongviet

*8월5일 -오늘부로 HTTP 관련 강의를 완강했다. HTTP에 대한 부분적인 이해만으로 프로젝트를 진행했었는데, 이번 기회로 기초를 다진 느낌이다. *HTTP 헤더 캐시 -캐시가 없을 때는 특정한 자료 요청 할 때마다 헤더와 바디로 구성된걸 계속 새로 보냄; 속도,비용면에서 매우 비효율적 -캐시 적용 시 HTTP header에 cache-control : max-age=60으로 넣으면, 60초 동안 해당 캐시 유효함을 나타냄. 따라서 브라우저 캐시에 60초 동안 해당 이미지가 유효해서 재 요청 시에도 서버로 가지않고 브라우저 캐시에서 꺼내서 씀. 따라서 속도 비용면에서 매우 효율적; ->캐시 유효시간 초과 시, 새롭게 서버에서 데이터 내려주고, 기존 캐시 덮어써서 60초 유효시간 리셋; 즉 네트워크는 ..

*8월4일 ***HTTP 일반 헤더 -HTTP 전송에 필요한 모든 부가정보를 담음. 메시지 바디 내용 & 크기, 압축, 인증, 요청클라이언트, 서버정보, 캐시관리정보 등 매우 많은 정보가 담김 -RFC 7230~7235 등장!! in 2014; entity -> representation로 용어 변경 -body가 실제 전달할 데이터를 가짐; 메시지 본문을 payload라고 함. -헤더는 바디 내 데이터를 해석할 수 있는 정보를 제공함 *Represesntation - 표현 -JSON, XML, HTML 등으로 표현하는 것 / 전송과 응답에 둘다 사용 할 수 있음 1)Content-Type : 데이터의 형식 text/html; charset=utf-8 applicataion/json //디폴트가 utf-8..

*8월3일 *각종 HTTP 상태 코드 -클라이언트가 보낸 요청의 처리 상태를 응답해서 알려주는 기능 1)1xx informational : 요청이 수신되어 처리중; 거의 사용되지 않음 2)2xx successful : 요청 정상 처리 200 OK //get방식 조회에 대한 응답 201 Created //post 방식으로 데이터 전달하고 서버에서 리소스 생성 202 Accepted //요청이 접수 되었으나 처리가 완료되지 않음. 예를 들어 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리하는 구조 204 No Content //서버가 요청을 성공적으로 수행했지만, 응답 본문에 보낼 데이터가 없음. 예를 들어 웹문서 편집기에 save 버튼 3)3xx redirection : 요청을 완료하려면 클라이언트..

*8월2일 ***상황에 따른 API 설계 *클라이언트 -> 서버 데이터 전달 방식 1)쿼리파라미터를 통한 데이터 전송 -get, 검색시 사용 2)메시지 바디를 통한 데이터 전송 -post, put, patch / 회원가입, 상품주문, 리소스등록, 리소스 변경 *클라이언트 -> 서버 데이터 전송 상황 -정적 데이터 조회 / 동적 데이터 조회 / HTML form을 통한 데이터 전송 / HTTP API를 통한 데이터 전송 1)정적 데이터 조회 -이미지, 문서 조회. 정적 데이터는 일반적으로 쿼리파라미터 없이 조회 가능 2)동적 데이터 조회 -검색, 게시판 목록, 필터 3)HTML form 데이터 전송(=Control URI) -get, post만 지원. ajax 기술쓰면 확장 가능 하긴 함. -등록폼, 수정..

*8월1일 *HTTP 구조 -요청 메세지와 응답 메세지 구조가 다름. -200 성공 / 400 클라이언트 요청 오류 / 500 서버 내부 오류 등 기본 응답 코드 -HTTP 헤더에는 HTTP 전송에 필요한 모든 부가 정보가 다 들어 있음; 메세지 내용 및 크기, 압축, 인증, 요청 클라이언트 브라우저 정보, 서버 애플리케이션 정보 등등; 필요한 메타 데이터 정보가 다 있다고 보면 됨. -HTTP 바디에는 실제 전송할 데이터가 있음. HTML문서, 이미지, 영상, JSON 등 byte로 표현할 수 있는 모든 데이터가 전송 가능함. -단순하고 확장 가능함. 일반구조 시작라인 헤더 공백라인(CRLF) 바디 요청메세지 구조 GET/search?a=b&c=d HTTP/1.1 Host: www~~ 공백라인 응답메세..

*8월1일 -HTTP 본격 진입 전, 여러 개념에 대해 정리 해보자. *인터넷 네트워크, IP protocol -클라이언트 해저케이블, 위성, 수 많은 노드들..... 서버 -from 2.3.50.12 to 30.50.100.2로 req, res하며 client & server packet으로 데이터 전달 -IP의 경우 비연결성, 비신뢰성, 프로그램 구분 불가 등으로 한계가 있음. *TCP -TCP가 IP의 한계를 해결 해줌. Transmission Control Protocol로 데이터 전달 보증, 순서보장, 연결 지향(3way handshake) 등을 특징으로 함. IP의 한계를 TCP/IP로 보완해줌. -IP와 달리 TCP는 port, 순서, 검증정보가 존재함. -연결지향이란, 클라이언트와 서버 모..

*7월28일 -구글링과 유튜브 무료 강의를 통해서 단편적으로만 습득했던 HTTP에 대한 종합적인 개념 정리를 위해, 스프링 개념잡기에 도움 주셨던 김영한님의 강의로 구매했다. 말투에서 뭔가 경상도의 향기가 나서, 강의 들으면서 고향 생각이 나게 해주는 고마운 분이다. -내일 2건의 픽스된 일정만 잘 소화하고, 나머지 시간 모두 HTTP 개념 확립에 쏟아야겠다. 2회독, 3회독해서 내 것으로 만들자.