반응형

※ 서버의 상황

- DNS 서버 : G사에서 회사 도메인을 관리

- 메일 발송 서버 : E사, N사에서 메일 서버를 둠

- E사는 회사 ERP 메일이며, N사는 noreply 메일로 활용

- 메일 발송 시 같은 "@도메인.com"을 사용

 

이슈 : N사의 메일서버에서 사내 ERP 메일에 메일 발송 시 스팸처리 되는 이슈

원인 : 도메인 서버 레코드에 사내 ERP MX레코드 누락

해결 : 도메인 서버 레코드에 사내 ERP MX레코드 등록

※ 사내 ERP 메일 서버 담당자에게 문의 하여 해결

반응형
반응형

※ 서버의 상황

- DNS 서버 : G사에서 회사 도메인을 관리

- 메일 발송 서버 : E사, N사에서 메일 서버를 둠

- E사는 회사 ERP 메일이며, N사는 noreply 메일로 활용

- 메일 발송 시 같은 "@도메인.com"을 사용

 

이슈 : 회사 메일 서버에서 gmail로 메일이 발송이 안되는 이슈가 발생

 

원인 : 메일의 DNS의 인증이 필요하도록 google의 정책 변경

※ google의 정책 : DNS에 SPF인증을 해야 수신이 가능하도록 함.

 

대응

: E사의 gmail 메일 서버 발송 정책 : SPF 인증만으로 gmail 발송

- E사의 메일서버에 SPF를 G사의 DNS서버 Record에 등록시킴

 

: N사의 gmail 메일 서버 발송 정책 : SPF, DKIM, DMARC의 인증이 있어야 gmail 발송

- N사의 메일서버에 SPF, DKIM, DMARC를 G사의 DNS서버 Record에 등록시키려 했으나,

G사의 Record의 바이트수가 DKIM을 담을 수 없어 이슈 발생

- G사, N사 모두 DNS를 바꾸던지 Mail 서버를 바꾸라는 답변

- DNS 서버를 N사로 변경(G사의 도메인의 네임서버를 N사로 설정)

- N사의 메일서버에 SPF, DKIM, DMARC를 N사의 DNS서버 Record에 등록

반응형
반응형
에러 메시지 :
org.springframework.restdocs.snippet.SnippetException: The following parts of the payload were not documented

 

{
  "list" : [ {
    "name" : "ai1"
  }, {
    "name" : "ai2"
  }, {
    "name" : "ai5"
  }, {
    "name" : "ai8"
  } ]
}
 
원인 : 에러메세지 밑에 있는 필드를 restdocs로 작성하지 않았다 or 오타
 
해결 방법 : test에서 name이라는 필드의 값을 찾아서 추가 또는 수정해준다.

fieldWithPath("name").type(JsonFieldType.STRING).description("인공지능 인스턴스 이름"),

 
※ 단순히 restdocs에서 작성 하지 않은 것만 보여주는 것이다. 
반응형
반응형

 

1. 속도 체크 방법
1) Pingdom 유료 툴 : 5개 국가 (Eastern US, Western Us, Europe, Eastern Asia, Australia)
2) chrome 개발자도구의 네트워크탭 + Touch VPN 무료 툴 :   Unite States, Russian Federation, Canada, France, Germany, Netherlands, Unite Kingdom)
 
2. 이슈
1) 모바일 접속 시 3~40초 대
2) pingdom 유럽 체크 시 3~40초대 pingdom grade D 67점
 
3. 현황
1) 개편이 여러번 됐으며, 개발자가 자주 바뀌면서 소스가 지저분함
2) 반응형 웹으로 모바일과 PC 버전이 한 소스파일에 등록되어있음
3) 보이지 않는 부분(PC접속시 mobile 버전, mobile 접속시 PC버전)까지 중복 resource를 가져옴
4) 서버가 국내에 위치(IDC가 따로 존재함)
5) 서버 구조
6) page size가 큰편이며, resources 자체가 많음
 
4. 대응 내역
1) 1차 대응(네트워크 이슈가 크다고 판단)
  • 파일 사이즈를 감소시키기 위한 대응
    • 이미지 파일 경량화 : 성과가 잘 나타났고 가장 대응하기 쉬웠음 (https://imagecompressor.com/ko/)
    • 쿼리 확인 : 메인 페이지였기 때문에 복잡한 쿼리가 없어 확인 후 수정하지 않음
  • 리소스를 감소 시키기위한 대응 
    • 컨텐츠 정비 : 성과가 잘 나타났으나, 감소시키는데 한계가 있으며, 개발공수가 들어감
    • css나 javscript 소스를 정리하는 방법에 대해서 고민을 했지만 공수가 많이 들고, 공통으로 쓰는게 있어서 불가능하다고 판단 
  • 모바일 대응
    • 하이브리드 앱이였던 서비스를 모바일 웹뷰로 전환 : 속도에 대한 성과가 거의 없었으며, 비용이 많이 나갔음
  • 속도 관련 컨설팅 업체 미팅(결국 컨설팅을 받지 않음)
    • Meta****
      • 부하테스트를 해본 후 솔루션을 제공할 수 있다고 함
      • 네트워크 구간의 테스트는 힘들며 테스트를 한다해도 해결 방안이 없다는 의견
    • ****Korea
      • 내부 보안 장비에 대한 이슈 테스트(느려지는 구간 파악 후 서버의 설정을 바꾸는 의견제시)
      • TTFB(브라우져가 요청 후 첫 바이트를 수신할때 까지의 시간)테스트 : 쿼리 성능 및 웹서버 성능에 대한 이슈 검토
      • 정적인 컨텐츠를 웹서버에서 분리 하는것 권장(IDC 영역)
      • 사용자 접속 지역에 따라 가장 가까운 캐싱 서버를 이용하도록 권장(비용이 들어감)
      • 동적캐싱(홀사이트 캐싱) 권장 (개발공수가 들어감)
      • 통신사에 라우팅 구간에 대한 검토를 요청(비협조적)
 
2) 2차 대응(메인 개편 후 적용)
  • 리소스를 감소 시키기위한 대응 
    • lazy loading 적용
      • JSP 화면단 <head>태그에 jquery.lazyload.min.js 임포트
      • 공통으로 사용하는 javascript에 lazyloading 설정
$(function(){
    $("img.lazy").lazyload({
        threshold: 500,
        effect : "fadeIn"
    });
});
      • JSP 화면단에서 img 태그의 class 추가 및 src 대신 data-original로 변경
<img class="lazy" data-original="../../img.png" alt="" />
      • 이슈 사항 : img 태그를 감싸고있는 상위 element의 속성이 style= "display:none;" 에 대한 부분을 컨트롤 하지 못함
    • http로 request하는 이미지들에 대해 https로 수정
      • 서비스가 ssl이 적용이 되어있어 소스 내부에 있는 이미지들을 http로 request 할 경우 https로 재 request를 하여 두번 호출하는 경우가 생김
    • javascript중 비동기 처리가 가능 한 부분을 비동기처리
      • 호출 순서에 연관이 없는 javscript에 대해 비동기 처리
 
 
3) 3차 대응
  • 파일 사이즈를 감소시키기 위한 대응
    • 이미지 파일 경량화 : 1차 대응 때와는 다르게 성과가 없었음 (https://imagecompressor.com/ko/)
    • 컨텐츠를 줄일 수 없는 상황이였으며, 리소스를 감소시킬 수 있는 방안에 대해 모색하여야 했음
  • 리소스를 감소 시키기위한 대응 
    • 사용하는 css와 javscript 소스를 판단하는 방법을 찾음
      • chrome의 개발자도구 → ctrl + shift + p  >show coverage 입력 coverage탭에서 ● 버튼 클릭
      • 사용중/미사용중인 javascript와 css가 표시됨(소스단위로 까지 볼수 있음)
    • css 파일 정리
기존 jsp 화면단 소스
<link rel="stylesheet" href="/css/common.css" type="text/css" />
 
기존 common.css 내부 소스
@charset 'utf-8';
@import url(css/css1.css);
@import url(css/css2.css);
@import url(css/css3.css);
 
개선한 jsp 화면단 소스
<link rel="stylesheet" href="/css/css1.css" type="text/css" />
<link rel="stylesheet" href="/css/css2.css" type="text/css" />
<link rel="stylesheet" href="/css/css3.css" type="text/css" />
 
      • 안쓰는 css 정리 및 css 파일 하나로 merge
        • 23개의 css파일을 → 4개로 줄임(리소스개수가 확 줄었고, pingdom grade도 증가했으며, 속도를 극적으로 줄여줌)
 
    • javascript 파일 정리
      • 안쓰는 javascript 정리 : 리소스 개수는 크게 줄진 않았으며, 속도를 조금 줄여줌
      • 비동기 처리가 가능한 javscript 정리 :  2차 대응때 했던 호출순서에 연관없는 javascript 비동기 처리를 늘림
      • javascript 순서 정리
        • DOMContentload 단계에 영향이 있는 script를 <head> 태그 내부로 이동
prioriry(우선순위)를 Highest 수준으로 설정
        • load 단계에 영향이 있는 script를 <body> 태그 내부 제일 마지막 부분으로 이동
웹브라우저가 HTML 문서를 해석할 때 <script> 태그를 만나면 그 안에 있는 javascript 의 처리가 끝날 때 까지 다른 HTML의 해석을 멈추기 때문에 body 태그 하단에 배치
prioriry(우선순위)를 Mideum 수준으로 설정
        • 초기 랜더링에 영향이 없는 script는 defer attribute를 추가 
prioriry(우선순위)를 Low 수준으로 설정
<script defer type="text/javascript" src="/js/egovframework//common/common.js" ></script>
        • 메인 페이지에 종속성이 없는 script(광고삽입 코드 등..) async 처리
 
    • 모바일 컨텐츠 줄이기
      • 호출하는 이미지 갯수를 감소시킴(속도에 영향이 거의 없었음)
 
    • 네트워크 연결 관련 설정 추가
      • 이미지 파일이 위치한 DNS 서버 prefetch 적용 (이미지 서버에서 모든 이미지마다 이미지서버의 dns lookup을 하는데 그 시간을 단축)
      • JSP 화면단 <head>태그에 미리 dns 서버의 정보를 심어둠  
<link rel="dns-prefetch" href="http://web.server.com">
 
    • css sprite 기법 적용
      • 같은 사이즈의 연속되는 심볼 이미지 파일을 하나의 png 파일로 묶은 후 이미지 경량화 및 css 수정
        • css 파일
 #top{background:url(../../img/category.png) no-repeat 0 0; text-indent:-99999px; display: inline-block; width:60px; height:50px;}
.top_img1{background-position:0px 0px !important;}
.top_img2{background-position: -60px 0px !important;}
.top_img3{background-position: -120px 0px !important;}
.top_img4{background-position: -180px 0px !important;}
.top_img5{background-position: -240px 0px !important;}
.top_img6{background-position: -300px 0px !important;}
.top_img7{background-position: -360px 0px !important;}
 
.top_img8{background-position:0px -50px !important;}
.top_img9{background-position: -60px -50px !important;}
.top_img10{background-position: -120px -50px !important;}
.top_img11{background-position: -180px -50px !important;}
.top_img12{background-position: -240px -50px !important;}
.top_img13{background-position: -300px -50px !important;}
.top_img14{background-position: -360px -50px !important;}
 
        • JSP 화면단
<span class="top_img${idx.count }" id="top"></span>
 
5. 결과
1) 3~40초대에 육박하는 load time을 최소 12초 까지 줄어들었음
2) pingdom grade가 67점 에서 71점으로 올랐으며, D등급에서 C등급으로 상승
3) 페이지 사이즈 : 747.64KB , Requests 수 : 90
 
6. 마무리
1)  진행한 작업 순서
  • 이미지 파일 경량화
  • 쿼리확인
  • 컨텐츠 줄이기
  • 하이브리드앱을 웹뷰로 전환
  • lazyloading 적용
  • http로 request하는 이미지들에 대해 https로 수정
  • javascript중 비동기 처리가 가능 한 부분을 비동기처리
  • 이미지 파일 재경량화
  • css 파일 merge
  • css 파일 분리(한 css 파일에 import된 css JSP 화면단으로 분리)
  • 덜쓰는 css 파일 merge 후 삭제
  • 안쓰는 css 파일 삭제 
  • 덜쓰는 javscript 파일 merge 후 삭제
  • 안쓰는 javascript 삭제
  • DOMContentload 단계에 영향이 있는 script를 <head> 태그 내부로 이동
  • load 단계에 영향이 있는 script를 <body> 태그 내부 제일 마지막 부분으로 이동
  • 초기 랜더링에 영향이 없는 script는 defer attribute를 추가 
  • 메인 페이지에 종속성이 없는 script(광고삽입 코드 등..) async 처리
  • 모바일 컨텐츠 줄이기
  • 이미지 파일이 위치한 DNS 서버 prefetch 적용
  • css sprite 기법 적용
 
2) 네트워크 이슈는 배제할수 없으나 소스상에서 줄일 수 있는 부분은 최대한 줄여보는것을 추천

 

7. 추가 대응

jstl 태그 c:if 또는 c:forEach 등의 사용으로 무분별한 개행처리가 되어 메인 페이지의 소스를 3만줄 이상 road함

개행처리에 대해 소스 수정

속도 이슈에 긍정적인 효과가 꽤 컸음

반응형
반응형


코드메세지설명
1XXInformational(정보)정보 교환.
100Continue클라이언트로부터 일부 요청을 받았으니 나머지 요청 정보를 계속 보내주길 바람. (HTTP 1.1에서 처음 등장)
101Switching Protocols서버는 클라이언트의 요청대로 Upgrade 헤더를 따라 다른 프로토콜로 바꿀 것임. (HTTP 1.1에서 처음 등장)
2XXSuccess(성공)데이터 전송이 성공적으로 이루어졌거나, 이해되었거나, 수락되었음.
200OK에러 없이 전송 성공.
202Accepted서버가 클라이언트의 요청을 수락함.
203Non-authoritavive Information서버가 클라이언트 요구중 일부만 전송.
204Non Content클라이언트의 요구를 처리했으나 전송할 데이터가 없음.
205Reset Content새 문서 없음. 하지만 브라우저는 문서 창을 리셋해야 함. (브라우저가 CGI 폼 필드를 전부 지우도록 할 때 사용됨.) (HTTP 1.1에서 처음 등장)
206Partial Content클라이언트가 Range 헤더와 함께 요청의 일부분을 보냈고 서버는 이를 수행했음. (HTTP 1.1에서 처음 등장)
3XXRedirection(방향바꿈)자료의 위치가 바뀌었음.
300Multiple Choisces최근에 옮겨진 데이터를 요청.
301Moved Permanently요구한 데이터를 변경된 URL에서 찾았음.
302Moved Permanently요구한 데이터가 변경된 URL에 있음을 명시. 301과 비슷하지만 새 URL은 임시 저장 장소로 해석됨.
303See Other요구한 데이터를 변경하지 않았기 때문에 문제가 있음.
304Not modified클라이언트의 캐시에 이 문서가 저장되었고 선택적인 요청에 의해 수행됨 (보통 지정된 날짜보다 더 나중의 문서만을 보여주도록 하는 If-Modified-Since 헤더의 경우).
305Use Proxy요청된 문서는 Location 헤더에 나열된 프록시를 통해 추출되어야 함. (HTTP 1.1에서 처음 등장)
307Temporary Redirect자료가 임시적으로 옮겨짐.
4XXClient Error(클라이언트 에러)클라이언트 측의 에러. 주소를 잘못 입력하였거나 요청이 잘못 되었음.
400Bad Request요청 실패. 문법상 오류가 있어서 서버가 요청사항을 이해하지 못함,
401.1Unauthorized권한 없음 (접속실패). 서버에 로그온 하려는 요청사항이 서버에 들어있는 권한과 비교했을 때 맞지 않음.
401.2Unauthorized권한 없음 (서버설정으로 인한 접속 실패). 서버에 로그온 하려는 요청사항이 서버에 들어있는 권한과 비교했을 때 맞지않음.
401.3Unauthorized권한 없음 (자원에 대한 ACL에 기인한 권한 없음). 클라이언트가 특정 자료에 접근할 수 없음.
401.4Unauthorized권한 없음 (필터에 의한 권한 부여 실패). 서버에 접속하는 사용자들을 확인하기 위해 설치한 필터 프로그램이 있음.
401.5Unauthorized권한 없음 (ISA PI/CGI 애플리케이션에 의한 권한부여 실패). 이용하려는 서버의 주소에 ISA PI나 CGI프로그램이 설치되어 있고, 권한을 부여할 수 없음.
402Payment Required예약됨.
403.1Forbidden금지 (수행접근 금지). 수행시키지 못하도록 되어있는 디렉토리 내의 실행 파일을 수행하려고 하였음.
403.2Forbidden금지 (읽기 접근 금지). 접근한 디렉토리에 가용한 디폴트 페이지가 없음.
403.4Forbidden금지 (SSL 필요함). 접근하려는 페이지가 SSL로 보안유지 되고 있음.
403.5Forbidden금지 (SSL 128필요함). 페이지가 128비트의 SSL로 보안유지 되고 있음.
403.6Forbidden금지 (IP 주소 거부됨). 사용자가 허용되지 않은 IP로부터 접근함.
403.7Forbidden금지 (클라이언트 확인 필요). 클라이언트가 자료에 접근할 수 있는지 확인 요함.
403.8Forbidden금지 (사이트 접근 거부됨). 서버가 요청사항을 수행하고 있지 않거나, 해당 사이트에 접근하는 것이 허락되지 않음.
403.9Forbidden접근금지 (연결된 사용자수 과다). 서버가 BUSY 상태에 있어서 요청을 수행할 수 없음.
403.1Forbidden접근금지 (설정이 확실 하지 않음).
403.11Forbidden접근금지 (패스워드 변경됨). 잘못된 패스워드를 입력했음.
403.12Forbidden접근금지(Mapper 접근 금지됨). 클라이언트 인증용 맵이 해당 웹 사이트에 접근하는 것이 거부됨.
404Not Found문서를 찾을 수 없음. 서버가 요청한 파일이나 스크립트를 찾지 못함.
405Method not allowed메서드 허용안됨. 요청 내용에 명시된 메서드를 수행하기 위해 해당 자원의 이용이 허용되지 않음.
406Not Acceptable받아들일 수 없음.
407Proxy Authentication Required프록시 서버의 인증이 필요함.
408Request timeout요청 시간이 지남.
409Conflict요청을 처리하는데 문제가 있음. 보통 PUT 요청과 관계가 있다. 보통 틀린 버전의 파일을 업로드할 경우 발생함. (HTTP 1.1에서 새로 등장)
410Gone영구적으로 사용할 수 없음.
411Length Required클라이언트가 헤더에 Content-Length를 포함하지 않으면 서버가 처리할 수 없음.(HTTP 1.1에서 새로 등장)
412Precondition Failed선결조건 실패. 헤더에 하나 이상의 선결조건을 서버에서 충족시킬 수 없음.
413Request entity too large요청된 문서가 현재 서버가 다룰 수 있는 크기보다 큼. (HTTP 1.1에서 새로 등장)
414Request-URI too long요청한 URI가 너무 김.
415Unsupported media type요청이 알려지지 않은 형태임. (HTTP 1.1에서 새로 등장)
5XXServer Error(서버 에러)서버 측의 에러로 올바른 요청을 처리할 수 없음.
500Internal Server Error서버 내부 오류.
501Not Implemented필요한 기능이 서버에 설치되지 않았음.
502Bad gateway게이트웨이 상태 나쁨.
503Service Unavailable외부 서비스가 죽었거나 현재 멈춘 상태 또는 이용할 수 없는 서비스.
504Gateway timeout프록시나 게이트웨이의 역할을 하는 서버에서 볼 수 있음. 초기 서버가 원격 서버로부터 응답을 받을 수 없음. (HTTP 1.1에서 새로 등장)
505HTTP Version Not Supported해당 HTTP 버젼을 지원하지 않음.


반응형
반응형
인코딩 문제
server.xml에서 URIEncoding="UTF-8"  추가
 <ConnectorconnectionTimeout="20000"port="8080"protocol="HTTP/1.1"
  redirectPort="8443"URIEncoding="UTF-8"/>

web.xml에서 
<!-- ================== Built In Filter Definitions ===================== -->

  <!-- A filter that sets character encoding that is used to decode -->
  <!-- parameters in a POST request -->
    <filter>
        <filter-name>setCharacterEncodingFilter</filter-name>
        <filter-class>org.apache.catalina.filters.SetCharacterEncodingFilter</filter-class>
        <init-param>
            <param-name>encoding</param-name>
            <param-value>UTF-8</param-value>
        </init-param>
<!--         <async-supported>true</async-supported> -->
    </filter>

    <mime-mapping>
        <extension> htm</ extension>n
        <mime-type> text/html;charset=UTF-8</mime-type >
    </mime-mapping >
    <mime-mapping >
        <extension> html</ extension>
        <mime-type> text/html;charset=UTF-8</mime-type >
    </mime-mapping >
    <mime-mapping >
추가

eclipse안에서
window > Preferences > encoding 검색 > General\Workspace 에서 UTF-8 설정 > Web\CSS Files에서 UTF-8 설정 > Web\HTML Files에서 UTF-8 설정 > Web\JSP Files에서 UTF-8 설정

프로젝트 우클릭 > Preferties > Resource에서 UTF-8 설정


반응형

+ Recent posts