들어가며...

  1. 토비의스프링 AOP 정리(월요일까지)
  2. Context Switching 테코톡 준비
  3. 레벨 3 미션 1 1단계 리펙토링 후 단계 2 PR 보내기
  4. 레벨 3 한 주 미션 복습
  5. 블로그에 글 하나 포스팅하기

2019-O9-22 일요일 TIL

  • 토비의스프링 6장(AOP) 읽고 정리

2019-O9-23 월요일 TIL

  • 토비의스프링 6장(AOP) 읽고 정리

토비의스프링 AOP를 읽으면서 이번 미션에 적용하고 싶은 생각이 많이 들었다. 이번 미션은 WAS를 구현하는 것인데 핵심기능과 부가기능을 잘 나눠서 설계를 해야겠다고 생각했다.

2019-O9-24 화요일 TIL

HTTP Web Server 구현 리펙토링

포비 강의

  • 마감시간이 중요하다. 마감시간에 따라 적절한 품질을 만들어야 한다.
    • 우리가 만드는 것은 예술작품이 아니다. 사용자가 필요할 때 사용할 수 있어야 한다.

성능좋은 웹 애플리케이션 개발 - 캐싱

  • 웹은 브라우저로 요청을 보낸 즉시 모든 파일을 다운로드받는다. 여기서 성능 이슈가 발생한다.
  • 현재 캐싱은 정적인 자원에 대한 캐싱이다.
  • 현재는 정적인 파일이 엄청 많은 시점이다. 그러므로 정적인 파일을 캐싱하는 것은 성능면에서 매우 좋다.
  • 모든 컨트롤은 서버가 결정한다. 클라이언트는 따르기만 한다.
  • ETag
    • HTTP 응답 헤더
    • 파일에 대한 정보를 해쉬한 값이다.
    • 최초가 아닌 요청에 대해서 클라이언트는 ETag를 보낸다. 이를 서버가 확인하여 ETag가 같으면 304 메시지를 보낸다.
    • 304(Not Modified) 메시지에는 바디가 없다. 즉 헤더만 전송되며 성능 향상을 할 수 있다.
    • 만약 파일이 변경되었다면 200 응답이다.
    • 이 태그는 자신의 로컬에 자원이 있어야 사용가능하다.
  • Cache-Control
    • max-age: 설정된 시간동안은 서버에 요청을 보내지 않는다.
    • no-cache: 로컬에 저장하고 ETag를 사용하겠다. max-age는 0인 것과 같다. 이는 서버에 계속 요청을 보내겠다는 말이다.
    • no-store: 로컬에 저장도 안하겠다.
    • private, public: 이는 웹 서버가 여러 계층으로 나눠져 있을 떄 사용한다.
      • private: 중간 단계에서는 캐시하지 않는다.
      • public: 중간 단계에서도 캐시한다.
  • 브라우저는 url을 다르게 입력하면 다른 것으로 인식한다.
    • 쿼리 스트링으로 같은 기능의 url을 만들어도 url 자체가 변하면 다른 url로 인식한다.
  • 캐시 max-age를 길게 설정해놓고 그 기간 안에 정적 파일이 바뀌면 쿼리스트링으로 버전을 바꿔서 다른 url로 보내면 해결할 수 있다.

씨유 강의 - Network 기초

  • 응답 시간은 단순히 서버 개수를 늘린다고 성능이 향상되지 않는다.
  • 요청/응답 시간을 어떻게 줄일 것인가?
    • 지리적인 거리를 줄인다.
    • 트래픽을 효율적으로 처리한다. TCP 혼잡제어 알고리즘을 더 좋은 걸 쓴다.
    • 라우터 최적 경로 알고리즘을 개선한다.
    • TCP 커넥션 비용을 줄인다.(3-handshake개수를 줄인다.)
  • 문제 해결은 단계적으로 접근해야 한다.(OSI 7 Layer)
  • 미션 실습 구현하기

2019-O9-25 수요일 TIL

  • HTTP Web Server 구현 리펙토링

2019-O9-26 목요일 TIL

  • 미션 1 2단계
    • 정적 요청과 동적 요청을 나누기
      • 정적 요청: 단순히 파일을 요청하는 것, 파일 이름이 있어야 하므로 index.html 형태로 올 것
      • 동적 요청: url을 통해 동작을 요청함. user/create와 같은 형태
    • Web Server, WAS(servlet), Web Framework 구분하고 정리하기

Today Retrospective

이번 주 중간 점검을 하고 싶다. 아직까지 계획대로 집중하는 것이 힘들다. 살아가면서 계획을 세워서 맞춰갔던 경험이 적다보니 처음부터 계획한 대로 착착 할 수 있을 것이라는 생각은 하지 않았다. 그래도 계획한 것을 못하니까 기분이 좋지는 않다. 그래서 이번에도 후회하면서 계획을 잘지키기위해 어떻게 할지 몇가지 생각해 보았다.

  • 매일 하루동안 했던 계획 점검하기
  • 집중이 안될 때 집중하는 척하기
  • 벨로퍼트님 유튜브 라이브 때 같이 개발 및 하루 회고하기

우테코에서 한 크루가 벨로퍼트님이 유튜브에서 매일 한 시간씩 코딩 라이브를 한다고 했다. 벨로퍼트님이 만든 벨로그를 쓰고 있는 나로써 예전에 이미 구독을 눌렀는데, 자주 찾아보지는 못해서 처음 안 사실이었다. 벨로퍼트님의 유튜브에 들어가보니 600개가 넘는 코딩 라이브가 있었다. 이러한 꾸준함이 너무 존경스러웠다. 오늘 낮에 스마트폰으로 시간을 보내면서 한 글을 읽었다. 공부는 습관을 만드는 것이 중요하다는 말을 보았다. 계획을 짜는 습관을 들이려고 이 글을 쓰고 있는 것처럼 무언가 한 시간동안 개발 관련 일을 꾸준히 한다면 나에게도 좋은 습관 하나가 만들어지는 것은 아닐까 생각했다. 이 역시 그냥 하루 한 시간 뭘하자고 무작정하면 안할꺼 같아서 마침 벨로퍼트님이 한 시간동안 매일같이 라이브 코딩을 하므로 나도 이 시간에 무엇인가를 같이 해보고 싶다는 생각을 하게 되었다.

2019-O9-27 금요일 TIL

포비 강의 - 전송 코딩을 최적화 - 압축

  • 텍스트 파일(js, css, html)의 압축률은 70% ~ 80%이다.
  • 압축과 압축 해제하는 데 CPU 비용이 소모하지만, 네트워크 비용이 더 크기 때문에 압축하는 것이 의미가 있다.
  • 클라이언트와 서버간에 어떤 압축 알고리즘을 사용했는지 알아야 한다.
    • 서버는 응답 헤더에 content-encoding으로 보내준다.
    • 대부분 gzip을 사용한다.
  • 이미지 최적화도 있다.
  • 요청 수 최소화
    • 파일 통합 및 압축
      • 여러 개의 CSS, Javascript 파일을 하나로 통합 및 압축해서 보낸다.
      • jquery-3.4.1.min.js
    • 이미지 통합
      • CSS sprite 활용해서 여러 개의 아이콘 이미지를 하나의 이미지로 만들어서 사용한다.
    • data URI 활용
      • 구글 이미지 검색에서 이미지의 html 코드를 살펴보자.
        • base64를 통해 이진코드로 변경해서 html 파일과 같이 클라이언트로 보낸 후 클라이언트가 이를 디코딩한다.
        • base64를 사용하면 최대로 크기가 4배로 증가할 수 있지만 한 번의 요청으로 여러 개를 보낼 수 있어 네트워크 비용을 줄일 수 있다.
      • html에 여러 이미지 데이터를 포함하고 내보내어 요청 수를 줄였다.
  • HTML에서 CSS, Javascript 위치
    • CSS는 head 태그에 위치한다.
    • 브라우저는 렌더링 중에 자바스크립트를 만나게 되면 해석과 구현이 완료될 때까지 브라우저 렌더링을 멈추게 된다.
    • Javascript는 종료 body 태그 앞에 위치하는 것이 일반적이다.
  • domain sharding
    • 브라우저마다 요청을 보낼 때 기본적으로 생성되는 쓰레드가 설정되어 있다.
    • 쓰레드가 생성되는 기준은 하나의 도메인 기준이다.
    • 그러므로 도메인을 나누면 그만큼 쓰레드를 더 많이 생성하게 된다.
  • 성능 측정 도구 활용
    • https://developers.google.com/speed: url을 검색하면 캐싱, 압축 등등 여러 전략을 활용하여 점수를 보여주고 어떤 최적화가 필요한지 알려준다.
  • HTTP vs HTTPS
  • SSL(Secure Socket Layer)
    • TCP와 HTTP 사이에서 암호화를 수행한다.
    • 웹툰 03 SSL, 웹툰 04 SSL을 검색해서 웹툰을 통해 학습할 수 있다.
  • HTTP 2.0

2019-O9-28 토요일 TIL

정리할 것

  • HTTP 메시지 정리하기
  • 쿠기와 세션
  • Web Server, WAS, Web Framework의 차이점

마치며...

이번 주동안 주로 한 것은 HTTP WEB 서버 구현 미션이었다. 요구사항을 구현하면서 구조, 확장, 테스트를 생각하면서 하다보니 정말 힘들었던 것 같다. 시간도 오래 걸리고 생각보다 코드가 맘에 들지 않아 걱정이다. 미션을 수행하면서 한 크루의 말이 생각난다. 지금 구현하는 것이 Web Server인지 WAS인지 Web Framework인지 모르겠다는 것이다. 나는 그냥 아무것도 생각하지 않은 체 요구사항만을 구현하고 있었다. 이 기능이 웹 서버인지 WAS인지는 생각하지 않았다. 구현을 하면서 내가 무엇을 만들고 있는지 계속해서 생각하는 것이 중요한 것 같다. 어느정도까지 구현해야 하는 것을 알 수 있고, 프레임워크라면 사용자가 개발자라는 것을 생각해두고 구현해야 한다.

이번 주는 컨디션 관리를 못했다. 저번 주에도 체했었는데 어제 또 체하는 바람에 할 일을 못했다. 체력과 컨디션 관리가 매우 중요하게 느껴졌다.

포비는 포수타를 하면서 또 여러 생각해봐야 할 것들을 던져주었다.

미션을 머지(merge)하는 것이 궁극적인 목표가 아니다. 미션은 자기가 부족한 것을 채우기 위한 도구일 뿐이다.

대충 위와 같이 이야기했던 것으로 기억한다. 내가 부족한 점은 셀 수 없이 많다. 그 중에서 내가 잘하고 싶은 부분, 집중하고 싶은 부분을 정해서 미션을 통해 이에 대해 깊게 생각해야한다. 말은 쉽지만 막상 미션을 하다보면 요구사항을 구현하고 리펙토링하고 테스트를 짜다 적당한 시간이 되면 PR을 보내고 피드백을 고친다. 여기서 더 깊게 하고 싶은데 쉽지 않다. 마감 시간을 지키는 연습도 해야 하고 내가 부족한 부분을 깊게 파고는 것도 해야 한다. 어디까지 절충이 되야 할지도 잘 모르겠다. 역시나 답은 없다. 내가 찾아야 한다.